[PATCH 3/3] gpu: drm: vmwgfx: Remove unnecessary parameter from vmw_compat_shader_free()

[Masaru Nomura]

vm_compat_shader_manager is only used for drm_ht_remove_item() within the 
function.
As drm_ht_remove_item() does not need a paremeter drm_open_hash(> shaders),
vm_compat_shader_manager(*man) does not have to be passed to this function.

Signed-off-by: Masaru Nomura 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_shader.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_shader.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_shader.c
index bbb30c3..2fdbf8e 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_shader.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_shader.c
@@ -532,14 +532,12 @@ int vmw_compat_shader_lookup(struct 
vmw_compat_shader_manager *man,
 /**
  * vmw_compat_shader_free - Free a compat shader.
  *
- * @man: Pointer to the compat shader manager.
  * @entry: Pointer to a struct vmw_compat_shader.
  *
  * Frees a struct vmw_compat_shder entry and drops its reference to the
  * guest backed shader.
  */
-static void vmw_compat_shader_free(struct vmw_compat_shader_manager *man,
-  struct vmw_compat_shader *entry)
+static void vmw_compat_shader_free(struct vmw_compat_shader *entry)
 {
list_del(>head);
WARN_ON(drm_ht_remove_item(>hash));
@@ -602,7 +600,7 @@ void vmw_compat_shaders_revert(struct 
vmw_compat_shader_manager *man,
list_for_each_entry_safe(entry, next, list, head) {
switch (entry->state) {
case VMW_COMPAT_ADD:
-   vmw_compat_shader_free(man, entry);
+   vmw_compat_shader_free(entry);
break;
case VMW_COMPAT_DEL:
ret = drm_ht_insert_item(>shaders, >hash);
@@ -649,7 +647,7 @@ int vmw_compat_shader_remove(struct 
vmw_compat_shader_manager *man,

switch (entry->state) {
case VMW_COMPAT_ADD:
-   vmw_compat_shader_free(man, entry);
+   vmw_compat_shader_free(entry);
break;
case VMW_COMPAT_COMMITED:
drm_ht_remove_item(>hash);
@@ -804,7 +802,7 @@ void vmw_compat_shader_man_destroy(struct 
vmw_compat_shader_manager *man)

mutex_lock(>dev_priv->cmdbuf_mutex);
list_for_each_entry_safe(entry, next, >list, head)
-   vmw_compat_shader_free(man, entry);
+   vmw_compat_shader_free(entry);

drm_ht_remove(>shaders);

-- 
1.9.3

[PATCH 2/3] gpu: drm: Remove unnecessary parameter from drm_ht_remove_item()

[Masaru Nomura]

removed drm_open_hash from drm_ht_remove_item() as the parameter is
not used within the function.

Signed-off-by: Masaru Nomura 
---
Please review this patch carefully. The reason the parameter is passed
might be some historical one or clarity of which drm_open_hash
we remove an item from.

 drivers/gpu/drm/drm_auth.c  | 2 +-
 drivers/gpu/drm/drm_hashtab.c   | 2 +-
 drivers/gpu/drm/drm_stub.c  | 2 +-
 drivers/gpu/drm/ttm/ttm_object.c| 8 +++-
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 4 ++--
 drivers/gpu/drm/vmwgfx/vmwgfx_shader.c  | 4 ++--
 include/drm/drm_hashtab.h   | 2 +-
 7 files changed, 11 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index 3cedae1..f7ceea0 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -115,7 +115,7 @@ int drm_remove_magic(struct drm_master *master, drm_magic_t 
magic)
return -EINVAL;
}
pt = drm_hash_entry(hash, struct drm_magic_entry, hash_item);
-   drm_ht_remove_item(>magiclist, hash);
+   drm_ht_remove_item(hash);
list_del(>head);
mutex_unlock(>struct_mutex);

diff --git a/drivers/gpu/drm/drm_hashtab.c b/drivers/gpu/drm/drm_hashtab.c
index c3b80fd..a66447f 100644
--- a/drivers/gpu/drm/drm_hashtab.c
+++ b/drivers/gpu/drm/drm_hashtab.c
@@ -188,7 +188,7 @@ int drm_ht_remove_key(struct drm_open_hash *ht, unsigned 
long key)
return -EINVAL;
 }

-int drm_ht_remove_item(struct drm_open_hash *ht, struct drm_hash_item *item)
+int drm_ht_remove_item(struct drm_hash_item *item)
 {
hlist_del_init_rcu(>head);
return 0;
diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index 14d1646..6ffed45 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -166,7 +166,7 @@ static void drm_master_destroy(struct kref *kref)

list_for_each_entry_safe(pt, next, >magicfree, head) {
list_del(>head);
-   drm_ht_remove_item(>magiclist, >hash_item);
+   drm_ht_remove_item(>hash_item);
kfree(pt);
}

diff --git a/drivers/gpu/drm/ttm/ttm_object.c b/drivers/gpu/drm/ttm/ttm_object.c
index d2a0533..42f73a8 100644
--- a/drivers/gpu/drm/ttm/ttm_object.c
+++ b/drivers/gpu/drm/ttm/ttm_object.c
@@ -188,7 +188,7 @@ int ttm_base_object_init(struct ttm_object_file *tfile,
return 0;
 out_err1:
spin_lock(>object_lock);
-   (void)drm_ht_remove_item_rcu(>object_hash, >hash);
+   drm_ht_remove_item_rcu(>hash);
spin_unlock(>object_lock);
 out_err0:
return ret;
@@ -202,7 +202,7 @@ static void ttm_release_base(struct kref *kref)
struct ttm_object_device *tdev = base->tfile->tdev;

spin_lock(>object_lock);
-   (void)drm_ht_remove_item_rcu(>object_hash, >hash);
+   drm_ht_remove_item_rcu(>hash);
spin_unlock(>object_lock);

/*
@@ -390,11 +390,9 @@ static void ttm_ref_object_release(struct kref *kref)
container_of(kref, struct ttm_ref_object, kref);
struct ttm_base_object *base = ref->obj;
struct ttm_object_file *tfile = ref->tfile;
-   struct drm_open_hash *ht;
struct ttm_mem_global *mem_glob = tfile->tdev->mem_glob;

-   ht = >ref_hash[ref->ref_type];
-   (void)drm_ht_remove_item_rcu(ht, >hash);
+   drm_ht_remove_item_rcu(>hash);
list_del(>head);
spin_unlock(>lock);

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index 87df0b3..1780f5e 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -2185,13 +2185,13 @@ static void vmw_clear_validations(struct vmw_sw_context 
*sw_context)
 base.head) {
list_del(>base.head);
ttm_bo_unref(>base.bo);
-   (void) drm_ht_remove_item(_context->res_ht, >hash);
+   drm_ht_remove_item(>hash);
sw_context->cur_val_buf--;
}
BUG_ON(sw_context->cur_val_buf != 0);

list_for_each_entry(val, _context->resource_list, head)
-   (void) drm_ht_remove_item(_context->res_ht, >hash);
+   drm_ht_remove_item(>hash);
 }

 static int vmw_validate_single_buffer(struct vmw_private *dev_priv,
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_shader.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_shader.c
index 01cc8ea..bbb30c3 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_shader.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_shader.c
@@ -542,7 +542,7 @@ static void vmw_compat_shader_free(struct 
vmw_compat_shader_manager *man,
   struct vmw_compat_shader *entry)
 {
list_del(>head);
-   WARN_ON(drm_ht_remove_item(>shaders, >hash));
+   WARN_ON(drm_ht_remove_item(>hash));
WARN_ON(ttm_ref_object_base_unref(entry->tfile, entry->handle,
  

[PATCH 1/3] gpu: drm: vmwgfx: Fix memory leak by adding drm_ht_remove()

[Masaru Nomura]

drm_ht_remove() should be called in vmw_compat_shader_man_destroy()
This is because memory was allocated for (>shaders)->table by
vmw_compat_shader_man_create() -> drm_ht_create()
but this memory is not freed when vmw_compat_shader_mager is destroied.

Signed-off-by: Masaru Nomura 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_shader.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_shader.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_shader.c
index c1559eea..01cc8ea 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_shader.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_shader.c
@@ -806,6 +806,8 @@ void vmw_compat_shader_man_destroy(struct 
vmw_compat_shader_manager *man)
list_for_each_entry_safe(entry, next, >list, head)
vmw_compat_shader_free(man, entry);

+   drm_ht_remove(>shaders);
+
mutex_unlock(>dev_priv->cmdbuf_mutex);
kfree(man);
 }
-- 
1.9.3

[PATCH 0/3] gpu: drm: Fix memory leak in vmwgfx_shader.c

[Masaru Nomura]

This patch fixes memory leak detected by Kernel memory leak detector, 
and cleans up functions which call drm_ht_remove_item() and 
vmw_compat_shader_free() so that an unused parameter is not passed.

Part of logs from /sys/kernel/debug/kmemleak is as follows:

unreferenced object 0xc900086ed000 (size 32768):
  comm "plymouthd", pid 287, jiffies 4294682116 (age 5911.149s)
  hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
  backtrace:
[] kmemleak_alloc+0x4e/0xb0
[] __vmalloc_node_range+0x1b2/0x2a0
[] vzalloc+0x4b/0x50
[] drm_ht_create+0x65/0xa0 [drm]
[] vmw_compat_shader_man_create+0x78/0xb0 [vmwgfx]
[] vmw_driver_open+0x62/0xa0 [vmwgfx]
[] drm_open+0x1b7/0x4c0 [drm]
[] drm_stub_open+0xa5/0x100 [drm]
[] chrdev_open+0xb9/0x1a0
[] do_dentry_open+0x1ff/0x340
[] finish_open+0x31/0x40
[] do_last+0xa64/0x1190
[] path_openat+0xcd/0x670
[] do_filp_open+0x4d/0xb0
[] do_sys_open+0x13d/0x230
[] SyS_open+0x1e/0x20
unreferenced object 0xc900086e4000 (size 32768):
  comm "Xorg", pid 751, jiffies 4294687683 (age 5917.505s)
  hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
  backtrace:
[] kmemleak_alloc+0x4e/0xb0
[] __vmalloc_node_range+0x1b2/0x2a0
[] vzalloc+0x4b/0x50
[] drm_ht_create+0x65/0xa0 [drm]
[] vmw_compat_shader_man_create+0x78/0xb0 [vmwgfx]
[] vmw_driver_open+0x62/0xa0 [vmwgfx]
[] drm_open+0x1b7/0x4c0 [drm]
[] drm_stub_open+0xa5/0x100 [drm]
[] chrdev_open+0xb9/0x1a0
[] do_dentry_open+0x1ff/0x340
[] finish_open+0x31/0x40
[] do_last+0xa64/0x1190
[] path_openat+0xcd/0x670
[] do_filp_open+0x4d/0xb0
[] do_sys_open+0x13d/0x230
[] SyS_open+0x1e/0x20

Masaru Nomura (3):
  gpu: drm: vmwgfx: Fix memory leak by adding drm_ht_remove()
  gpu: drm: Remove unnecessary parameter from drm_ht_remove_item()
  gpu: drm: vmwgfx: Remove unnecessary parameter from
vmw_compat_shader_free()

 drivers/gpu/drm/drm_auth.c  |  2 +-
 drivers/gpu/drm/drm_hashtab.c   |  2 +-
 drivers/gpu/drm/drm_stub.c  |  2 +-
 drivers/gpu/drm/ttm/ttm_object.c|  8 +++-
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c |  4 ++--
 drivers/gpu/drm/vmwgfx/vmwgfx_shader.c  | 16 
 include/drm/drm_hashtab.h   |  2 +-
 7 files changed, 17 insertions(+), 19 deletions(-)

-- 
1.9.3

[Nouveau] [PATCH v2 2/3] drm/ttm: introduce dma cache sync helpers

[Alexandre Courbot]

On Tue, Jun 24, 2014 at 10:25 PM, Lucas Stach  wrote:
> Am Dienstag, den 24.06.2014, 14:27 +0200 schrieb Maarten Lankhorst:
>> op 24-06-14 14:23, Alexandre Courbot schreef:
>> > On Tue, Jun 24, 2014 at 7:55 PM, Alexandre Courbot > > nvidia.com> wrote:
>> >> On 06/24/2014 07:33 PM, Alexandre Courbot wrote:
>> >>> On 06/24/2014 07:02 PM, Russell King - ARM Linux wrote:
>>  On Tue, Jun 24, 2014 at 06:54:26PM +0900, Alexandre Courbot wrote:
>> > From: Lucas Stach 
>> >
>> > On architectures for which access to GPU memory is non-coherent,
>> > caches need to be flushed and invalidated explicitly at the
>> > appropriate places. Introduce two small helpers to make things
>> > easy for TTM-based drivers.
>> 
>>  Have you run this with DMA API debugging enabled?  I suspect you 
>>  haven't,
>>  and I recommend that you do.
>> >>>
>> >>> # cat /sys/kernel/debug/dma-api/error_count
>> >>> 162621
>> >>>
>> >>> (??? ???)
>> >>
>> >> *puts table back on its feet*
>> >>
>> >> So, yeah - TTM memory is not allocated using the DMA API, hence we cannot
>> >> use the DMA API to sync it. Thanks Russell for pointing it out.
>> >>
>> >> The only alternative I see here is to flush the CPU caches when syncing 
>> >> for
>> >> the device, and invalidate them for the other direction. Of course if the
>> >> device has caches on its side as well the opposite operation must also be
>> >> done for it. Guess the only way is to handle it all by ourselves here. :/
>> > ... and it really sucks. Basically if we cannot use the DMA API here
>> > we will lose the convenience of having a portable API that does just
>> > the right thing for the underlying platform. Without it we would have
>> > to duplicate arm_iommu_sync_single_for_cpu/device() and we would only
>> > have support for ARM.
>> >
>> > The usage of the DMA API that we are doing might be illegal, but in
>> > essence it does exactly what we need - at least for ARM. What are the
>> > alternatives?
>> Convert TTM to use the dma api? :-)
>
> Actually TTM already has a page alloc backend using the DMA API. It's
> just not used for the standard case right now.

Indeed, and Nouveau even already makes use of it if CONFIG_SWIOTLB is
set apparently.

> I would argue that we should just use this page allocator (which has the
> side effect of getting pages from CMA if available -> you are actually
> free to change the caching) and do away with the other allocator in the
> ARM case.

Mm? Does it mean that CMA memory is not mapped into lowmem? That would
certainly help in the present case, but I wonder how useful it will be
once the iommu support is in place. Will also need to consider
performance of such coherent memory for e.g. user-space mappings.

Anyway, I will experiment a bit with this tomorrow, thanks!

[PATCH 1/2] x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup()

[Bruno Prémont]

On Mon, 02 June 2014 Bruno Pr?mont  wrote:
> With commit b4aa0163056b ("efifb: Implement vga_default_device() (v2)")
> Matthew Garrett introduced a efifb vga_default_device() so that EFI
> systems that do not load shadow VBIOS or setup VGA get proper value for
> boot_vga PCI sysfs attribute on the corresponding PCI device.
> 
> Xorg is refusing to detect devices when boot_vga=0 which is the case on
> some EFI system (e.g. MacBookAir2,1). Xorg detects the GPU and finds
> the dri device but then bails out with "no devices detected".
> 
> Note: When vga_default_device() is set boot_vga PCI sysfs attribute
> reflects its state. When unset this attribute is 1 whenever
> IORESOURCE_ROM_SHADOW flag is set.
> 
> With introduction of sysfb/simplefb/simpledrm efifb is getting obsolete
> while having native drivers for the GPU also makes selecting
> sysfb/efifb optional.
> 
> Remove the efifb implementation of vga_default_device() and initialize
> vgaarb's vga_default_device() with the PCI GPU that matches boot
> screen_info in pci_fixup_video().

Quite a few people trip over this issue, apparently concentrated on
Apple Macs (EFI) with Nvidia graphics.

It has shown up in at least two bugzilla reports (as side-issue):
  https://bugs.freedesktop.org/show_bug.cgi?id=58556#c16
  https://bugs.freedesktop.org/show_bug.cgi?id=76732#c34

My initial report and discussion on freenode, #nouveau:
  http://people.freedesktop.org/~cbrill/dri-log/?channel=nouveau=2013-11-23
followed by initial patch proposal:
  http://permalink.gmane.org/gmane.comp.video.dri.devel/95943

[PATCH v2 2/3] drm/ttm: introduce dma cache sync helpers

[Alexandre Courbot]

On Tue, Jun 24, 2014 at 10:09 PM, Russell King - ARM Linux
 wrote:
> On Tue, Jun 24, 2014 at 09:23:05PM +0900, Alexandre Courbot wrote:
>> On Tue, Jun 24, 2014 at 7:55 PM, Alexandre Courbot  
>> wrote:
>> > The only alternative I see here is to flush the CPU caches when syncing for
>> > the device, and invalidate them for the other direction. Of course if the
>> > device has caches on its side as well the opposite operation must also be
>> > done for it. Guess the only way is to handle it all by ourselves here. :/
>>
>> ... and it really sucks. Basically if we cannot use the DMA API here
>> we will lose the convenience of having a portable API that does just
>> the right thing for the underlying platform. Without it we would have
>> to duplicate arm_iommu_sync_single_for_cpu/device() and we would only
>> have support for ARM.
>>
>> The usage of the DMA API that we are doing might be illegal, but in
>> essence it does exactly what we need - at least for ARM. What are the
>> alternatives?
>
> It may seem /to you/ as a driver developer to be the easiest thing in
> the world to abuse an API in a way that it's not supposed to be used,
> and it is easy to do that.
>
> However, what you're actually saying is that you don't respect your
> fellow kernel developers who have to maintain the other side of that
> interface.  When they need to change the implementation of that
> interface, what if those changes then screw your abuse of that
> interface.
>
> The reason we define the behaviours and properties of APIs is to give
> both the user and the implementer of the API some degree of latitude
> in how that interface works, so that it can be maintained into the
> future.  If abuses (such as these) are allowed, then we've lost,
> because the interface can no longer be sanely maintained - especially
> if driver authors eventually end up not caring about their pile of
> abuse they've created after they've moved on to new wonderful hardware.
>
> With an API such as the DMA API, where we have hundreds, if not a
> thousand users of it, this /really/ matters.
>
> We've been here before with the DMA API on older ARM platforms, where
> we've had people abusing the API or going beneath the API because "it
> does what they need it to", which then makes stuff much harder to change
> at architecture level.
>
> Last time it happened, it was when ARMv6 came along and ARM moved away
> from VIVT caches.  The options were either to break the crap drivers
> and support ARMv6+ CPUs, or keep the crap drivers working and not
> support DMA in any shape or form on ARMv6+.
>
> Obviously, this was too important to for one or two abusive drivers to
> block, so I changed the architecture level /anyway/ and just said screw
> the drivers which end up being broken by their short-sightedness, they
> can either rot or someone else can fix them.
>
> I have no beef for intentionally breaking stuff when people abuse well
> defined interfaces and/or refuse to discuss their requirements when
> interfaces don't quite do what they want - or worse, refuse to listen
> to objections.
>
> As I say, it's disrespectful to your fellow kernel developers to abuse
> well defined interfaces.

Apologies if I sounded that way - I wasn't suggesting that we carry on
with this clearly illegal usage of the DMA API, but was merely noting
that if we were to implement the intended behavior on our side it
would look just like what the ARM implementation currently does. My
question about alternatives wasn't rethorical, I am not so familiar
with this part of the system (as should be obvious by now) and would
like to know whether there aren't other solutions that would spare us
the need to re-implement something that already exists.

[PATCH 1/2] Revert "drm/radeon: remove drm_vblank_get|put from pflip handling"

[Dieter Nützel]

Am 24.06.2014 12:05, schrieb Michel D?nzer:
> On 24.06.2014 05:32, Dieter N?tzel wrote:
>> Am 23.06.2014 21:46, schrieb Dieter N?tzel:
>>> Am 23.06.2014 11:34, schrieb Michel D?nzer:
 On 18.06.2014 18:14, Christian K?nig wrote:
> Am 18.06.2014 07:53, schrieb Michel D?nzer:
>> 
>>   (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
>> completion
>> event has impossible msc [x-1] < target_msc [x]
>> 
>> messages in the X log file which have been popping up in bug 
>> reports
>> lately.
>> This also results in 0s being returned to the client for the MSC 
>> and
>> timestamp of the swap completion, which could cause all kinds of 
>> bad
>> behaviour.
> First of all thanks for looking into it. Are you getting this on
> 3.16 or
> 3.15?
 
 I haven't actually run into this myself yet. I thought I'd seen it 
 in
 several bug reports, but right now I can only find
 https://bugs.freedesktop.org/show_bug.cgi?id=80029#c17 , which seems 
 to
 include the page flipping changes from 3.16.
>>> 
>>> With 3.16-rc2 I get it now on my RV730 AGP as in the above bug 
>>> report.
>>> But only the lines in Xorg.0.log.
>>> NO signs of any damage/error in use.
>>> 
>>> Since 3.15 and 3.16 (rc2 only) my system is rock solid.
>>> 
>>> I've tried 3.15-rc7 + Christian's pflip rework (did some little
>>> handwork), too.
>>> It was solid but I saw the reported flip/black distortion in the 
>>> below
>>> part during Kwin 4.13 cube screen effect (rotation). Your fix for
>>> 3.16-rc1 fixed that.
> 
> That's good to hear.
> 
> 
>> I can reliable generate such lines in Xorg.0.log with KWin cube 
>> desktop
>> effect.
>> 
>> Rotate screens with mouse wheel or screen switcher => new entry in
>> Xorg.0.log. If it happens I notice ('see') flip delay.
> 
> I was only able to reproduce it a couple of times even with that, but 
> not
> at all yet with the patch below. Does it help for you as well?

Will try in the next run.

My daughter generated kernel crash for us.;-)
See would open up a zoom image in Konqi of a new Waveboard for here girl 
friends...

But I could only take images with my mobile.
kernel BUG at drivers/gpu/drm/drm_irq.c:976!
Will send one, have two more.

Greetings,
   Dieter

2nd, try.
This time without image.
Let me know where I should add it, please.

> 
> I don't think that the pflip irq is thrown earlier than the vblank, 
> but
> on 3.16 it might actually be that we program the flip so fast into 
> the
> hardware that we do it one frame earlier than planned.
 
 So userspace is notified of the previous vertical blank period and 
 calls
 the page flip ioctl in response, which then manages to program the
 scanout address update into the hardware before the scanout address
 update is latched during the previous vertical blank period?
> 
> I think there's another possible scenario:
> 
>  1. Userspace submits page flip intended for MSC x
>  2. The vertical blank interrupt is triggered for MSC x =>
> radeon_crtc_handle_vblank() => radeon_crtc_handle_flip()
>  3. Userspace submits page flip intended for MSC (x + 1)
>  4. The page flip interrupt is triggered for the previous flip =>
> radeon_crtc_handle_flip() => drm_send_vblank_event(). The second 
> flip
> hasn't actually executed yet, and the event has MSC x instead of (x 
> + 1)
> as expected by userspace.
> 
> If that is the case, only actually enabling and handling the page flip
> interrupt when a flip is pending might also avoid it. I can hack that 
> up
> tomorrow, if Christian doesn't beat me to it.
> 
> 
> diff --git a/drivers/gpu/drm/radeon/radeon_display.c
> b/drivers/gpu/drm/radeon/radeon_display.c
> index 8b575a4..8350f8c 100644
> --- a/drivers/gpu/drm/radeon/radeon_display.c
> +++ b/drivers/gpu/drm/radeon/radeon_display.c
> @@ -336,14 +336,19 @@ void radeon_crtc_handle_flip(struct
> radeon_device *rdev, int crtc_id)
> struct radeon_crtc *radeon_crtc = 
> rdev->mode_info.crtcs[crtc_id];
> struct radeon_flip_work *work;
> unsigned long flags;
> +   struct timeval vblank_time;
> +   u32 vblank_seq;
> 
> /* this can happen at init */
> if (radeon_crtc == NULL)
> return;
> 
> +   vblank_seq = drm_vblank_count_and_time(rdev->ddev, crtc_id,
> _time);
> +
> spin_lock_irqsave(>ddev->event_lock, flags);
> work = radeon_crtc->flip_work;
> -   if (work == NULL) {
> +   if (work == NULL ||
> +   (vblank_seq - work->event->event.sequence) > (1<<23)) {
> spin_unlock_irqrestore(>ddev->event_lock, flags);
> return;
> }
> @@ -379,6 +384,7 @@ static void radeon_flip_work_func(struct
> work_struct *__work)
> 
> struct drm_crtc *crtc = _crtc->base;
> struct drm_framebuffer *fb = work->fb;
> +   struct timeval vblank_time;
> 
> uint32_t tiling_flags, 

[PATCH v2 2/3] drm/ttm: introduce dma cache sync helpers

[Alexandre Courbot]

On Tue, Jun 24, 2014 at 7:55 PM, Alexandre Courbot  
wrote:
> On 06/24/2014 07:33 PM, Alexandre Courbot wrote:
>>
>> On 06/24/2014 07:02 PM, Russell King - ARM Linux wrote:
>>>
>>> On Tue, Jun 24, 2014 at 06:54:26PM +0900, Alexandre Courbot wrote:

 From: Lucas Stach 

 On architectures for which access to GPU memory is non-coherent,
 caches need to be flushed and invalidated explicitly at the
 appropriate places. Introduce two small helpers to make things
 easy for TTM-based drivers.
>>>
>>>
>>> Have you run this with DMA API debugging enabled?  I suspect you haven't,
>>> and I recommend that you do.
>>
>>
>> # cat /sys/kernel/debug/dma-api/error_count
>> 162621
>>
>> (??? ???)
>
>
> *puts table back on its feet*
>
> So, yeah - TTM memory is not allocated using the DMA API, hence we cannot
> use the DMA API to sync it. Thanks Russell for pointing it out.
>
> The only alternative I see here is to flush the CPU caches when syncing for
> the device, and invalidate them for the other direction. Of course if the
> device has caches on its side as well the opposite operation must also be
> done for it. Guess the only way is to handle it all by ourselves here. :/

... and it really sucks. Basically if we cannot use the DMA API here
we will lose the convenience of having a portable API that does just
the right thing for the underlying platform. Without it we would have
to duplicate arm_iommu_sync_single_for_cpu/device() and we would only
have support for ARM.

The usage of the DMA API that we are doing might be illegal, but in
essence it does exactly what we need - at least for ARM. What are the
alternatives?

[Nouveau] [PATCH v2 2/3] drm/ttm: introduce dma cache sync helpers

[Stéphane Marchesin]

On Tue, Jun 24, 2014 at 6:25 AM, Lucas Stach  wrote:
> Am Dienstag, den 24.06.2014, 14:27 +0200 schrieb Maarten Lankhorst:
>> op 24-06-14 14:23, Alexandre Courbot schreef:
>> > On Tue, Jun 24, 2014 at 7:55 PM, Alexandre Courbot > > nvidia.com> wrote:
>> >> On 06/24/2014 07:33 PM, Alexandre Courbot wrote:
>> >>> On 06/24/2014 07:02 PM, Russell King - ARM Linux wrote:
>>  On Tue, Jun 24, 2014 at 06:54:26PM +0900, Alexandre Courbot wrote:
>> > From: Lucas Stach 
>> >
>> > On architectures for which access to GPU memory is non-coherent,
>> > caches need to be flushed and invalidated explicitly at the
>> > appropriate places. Introduce two small helpers to make things
>> > easy for TTM-based drivers.
>> 
>>  Have you run this with DMA API debugging enabled?  I suspect you 
>>  haven't,
>>  and I recommend that you do.
>> >>>
>> >>> # cat /sys/kernel/debug/dma-api/error_count
>> >>> 162621
>> >>>
>> >>> (??? ???)
>> >>
>> >> *puts table back on its feet*
>> >>
>> >> So, yeah - TTM memory is not allocated using the DMA API, hence we cannot
>> >> use the DMA API to sync it. Thanks Russell for pointing it out.
>> >>
>> >> The only alternative I see here is to flush the CPU caches when syncing 
>> >> for
>> >> the device, and invalidate them for the other direction. Of course if the
>> >> device has caches on its side as well the opposite operation must also be
>> >> done for it. Guess the only way is to handle it all by ourselves here. :/
>> > ... and it really sucks. Basically if we cannot use the DMA API here
>> > we will lose the convenience of having a portable API that does just
>> > the right thing for the underlying platform. Without it we would have
>> > to duplicate arm_iommu_sync_single_for_cpu/device() and we would only
>> > have support for ARM.
>> >
>> > The usage of the DMA API that we are doing might be illegal, but in
>> > essence it does exactly what we need - at least for ARM. What are the
>> > alternatives?
>> Convert TTM to use the dma api? :-)
>
> Actually TTM already has a page alloc backend using the DMA API. It's
> just not used for the standard case right now.
>
> I would argue that we should just use this page allocator (which has the
> side effect of getting pages from CMA if available -> you are actually
> free to change the caching) and do away with the other allocator in the
> ARM case.

CMA comes with its own set of (severe) limitations though, in
particular it's not possible to map arbitrary CPU pages into the GPU
without incurring a copy, you add arbitrary memory limits etc. Overall
that's not really a good pick for the long term...

St?phane

[PATCH RFC v2 8/8] component: track components via array rather than list

[Russell King]

Since we now have an array which defines each component, maintain the
components to be bound in the array rather than a separate list.  We
also need duplicate tracking so we can eliminate multiple bind calls
for the same component: we preserve the list-based component order in
that the first match which adds the component determines its position.

Signed-off-by: Russell King 
---
 drivers/base/component.c | 140 +--
 1 file changed, 62 insertions(+), 78 deletions(-)

diff --git a/drivers/base/component.c b/drivers/base/component.c
index 0863cfeea769..8a1d784a9759 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -18,18 +18,21 @@
 #include 
 #include 

+struct component;
+
 struct component_match {
size_t alloc;
size_t num;
struct {
void *data;
int (*fn)(struct device *, void *);
+   struct component *component;
+   bool duplicate;
} compare[0];
 };

 struct master {
struct list_head node;
-   struct list_head components;
bool bound;

const struct component_master_ops *ops;
@@ -39,7 +42,6 @@ struct master {

 struct component {
struct list_head node;
-   struct list_head master_node;
struct master *master;
bool bound;

@@ -63,46 +65,20 @@ static struct master *__master_find(struct device *dev,
return NULL;
 }

-/* Attach an unattached component to a master. */
-static void component_attach_master(struct master *master, struct component *c)
-{
-   c->master = master;
-
-   list_add_tail(>master_node, >components);
-}
-
-/* Detach a component from a master. */
-static void component_detach_master(struct master *master, struct component *c)
-{
-   list_del(>master_node);
-
-   c->master = NULL;
-}
-
-/*
- * Add a component to a master, finding the component via the compare
- * function and compare data.  This is safe to call for duplicate matches
- * and will not result in the same component being added multiple times.
- */
-static int component_master_add_child(struct master *master,
+static struct component *find_component(struct master *master,
int (*compare)(struct device *, void *), void *compare_data)
 {
struct component *c;
-   int ret = -ENXIO;

list_for_each_entry(c, _list, node) {
if (c->master && c->master != master)
continue;

-   if (compare(c->dev, compare_data)) {
-   if (!c->master)
-   component_attach_master(master, c);
-   ret = 0;
-   break;
-   }
+   if (compare(c->dev, compare_data))
+   return c;
}

-   return ret;
+   return NULL;
 }

 static int find_components(struct master *master)
@@ -116,26 +92,35 @@ static int find_components(struct master *master)
 * any components which are found to this master.
 */
for (i = 0; i < match->num; i++) {
-   ret = component_master_add_child(master,
-match->compare[i].fn,
-match->compare[i].data);
-   if (ret)
+   struct component *c;
+
+   if (match->compare[i].component)
+   continue;
+
+   c = find_component(master, match->compare[i].fn,
+  match->compare[i].data);
+   if (!c) {
+   ret = -ENXIO;
break;
+   }
+
+   /* Attach this component to the master */
+   match->compare[i].duplicate = !!c->master;
+   match->compare[i].component = c;
+   c->master = master;
}
return ret;
 }

-/* Detach all attached components from this master */
-static void master_remove_components(struct master *master)
+/* Detach component from associated master */
+static void remove_component(struct master *master, struct component *c)
 {
-   while (!list_empty(>components)) {
-   struct component *c = list_first_entry(>components,
-   struct component, master_node);
-
-   WARN_ON(c->master != master);
+   size_t i;

-   component_detach_master(master, c);
-   }
+   /* Detach the component from this master. */
+   for (i = 0; i < master->match->num; i++)
+   if (master->match->compare[i].component == c)
+   master->match->compare[i].component = NULL;
 }

 /*
@@ -150,37 +135,25 @@ static int try_to_bring_up_master(struct master *master,
 {
int ret;

-   if (find_components(master)) {
-   /* Failed to find all components */
-   ret = 0;
-   goto out;
-   }
+  

[PATCH RFC v2 7/8] component: move check for unbound master into try_to_bring_up_masters()

[Russell King]

Clean up the code a little; we don't need to check that the master is
unbound for every invocation of try_to_bring_up_master(), so let's move
it to where it's really needed - try_to_bring_up_masters(), where we may
encounter already bound masters.

Signed-off-by: Russell King 
---
 drivers/base/component.c | 15 +--
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/drivers/base/component.c b/drivers/base/component.c
index c0a5b1abc931..0863cfeea769 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -150,13 +150,6 @@ static int try_to_bring_up_master(struct master *master,
 {
int ret;

-   if (master->bound)
-   return 0;
-
-   /*
-* Search the list of components, looking for components that
-* belong to this master, and attach them to the master.
-*/
if (find_components(master)) {
/* Failed to find all components */
ret = 0;
@@ -196,9 +189,11 @@ static int try_to_bring_up_masters(struct component 
*component)
int ret = 0;

list_for_each_entry(m, , node) {
-   ret = try_to_bring_up_master(m, component);
-   if (ret != 0)
-   break;
+   if (!m->bound) {
+   ret = try_to_bring_up_master(m, component);
+   if (ret != 0)
+   break;
+   }
}

return ret;
-- 
1.8.3.1

[PATCH RFC v2 6/8] component: remove old add_components method

[Russell King]

Now that drivers create an array of component matches at probe time, we
can retire the old methods.  This involves removing the add_components
master method, and removing component_master_add_child() from public
view.  We also remove component_add_master() as that interface is no
longer useful.

Signed-off-by: Russell King 
---
 drivers/base/component.c  | 21 +
 include/linux/component.h |  5 -
 2 files changed, 1 insertion(+), 25 deletions(-)

diff --git a/drivers/base/component.c b/drivers/base/component.c
index bd8b4908593b..c0a5b1abc931 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -84,7 +84,7 @@ static void component_detach_master(struct master *master, 
struct component *c)
  * function and compare data.  This is safe to call for duplicate matches
  * and will not result in the same component being added multiple times.
  */
-int component_master_add_child(struct master *master,
+static int component_master_add_child(struct master *master,
int (*compare)(struct device *, void *), void *compare_data)
 {
struct component *c;
@@ -104,7 +104,6 @@ int component_master_add_child(struct master *master,

return ret;
 }
-EXPORT_SYMBOL_GPL(component_master_add_child);

 static int find_components(struct master *master)
 {
@@ -112,14 +111,6 @@ static int find_components(struct master *master)
size_t i;
int ret = 0;

-   if (!match) {
-   /*
-* Search the list of components, looking for components that
-* belong to this master, and attach them to the master.
-*/
-   return master->ops->add_components(master->dev, master);
-   }
-
/*
 * Scan the array of match functions and attach
 * any components which are found to this master.
@@ -289,9 +280,6 @@ int component_master_add_with_match(struct device *dev,
struct master *master;
int ret;

-   if (ops->add_components && match)
-   return -EINVAL;
-
/* Reallocate the match array for its true size */
match = component_match_realloc(dev, match, match->num);
if (IS_ERR(match))
@@ -323,13 +311,6 @@ int component_master_add_with_match(struct device *dev,
 }
 EXPORT_SYMBOL_GPL(component_master_add_with_match);

-int component_master_add(struct device *dev,
-   const struct component_master_ops *ops)
-{
-   return component_master_add_with_match(dev, ops, NULL);
-}
-EXPORT_SYMBOL_GPL(component_master_add);
-
 void component_master_del(struct device *dev,
const struct component_master_ops *ops)
 {
diff --git a/include/linux/component.h b/include/linux/component.h
index c00dcc302611..71c434a6a5ee 100644
--- a/include/linux/component.h
+++ b/include/linux/component.h
@@ -17,18 +17,13 @@ void component_unbind_all(struct device *, void *);
 struct master;

 struct component_master_ops {
-   int (*add_components)(struct device *, struct master *);
int (*bind)(struct device *);
void (*unbind)(struct device *);
 };

-int component_master_add(struct device *, const struct component_master_ops *);
 void component_master_del(struct device *,
const struct component_master_ops *);

-int component_master_add_child(struct master *master,
-   int (*compare)(struct device *, void *), void *compare_data);
-
 struct component_match;

 int component_master_add_with_match(struct device *,
-- 
1.8.3.1

[PATCH RFC v2 5/8] imx-drm: update to use component match support

[Russell King]

Update the imx-drm driver to use the component match support rather than
add_components.

Signed-off-by: Russell King 
---
 drivers/staging/imx-drm/imx-drm-core.c | 57 +++---
 1 file changed, 4 insertions(+), 53 deletions(-)

diff --git a/drivers/staging/imx-drm/imx-drm-core.c 
b/drivers/staging/imx-drm/imx-drm-core.c
index def8280d7ee6..47ee6c79857a 100644
--- a/drivers/staging/imx-drm/imx-drm-core.c
+++ b/drivers/staging/imx-drm/imx-drm-core.c
@@ -570,22 +570,6 @@ static int compare_of(struct device *dev, void *data)
return dev->of_node == np;
 }

-static LIST_HEAD(imx_drm_components);
-
-static int imx_drm_add_components(struct device *master, struct master *m)
-{
-   struct imx_drm_component *component;
-   int ret;
-
-   list_for_each_entry(component, _drm_components, list) {
-   ret = component_master_add_child(m, compare_of,
-component->of_node);
-   if (ret)
-   return ret;
-   }
-   return 0;
-}
-
 static int imx_drm_bind(struct device *dev)
 {
return drm_platform_init(_drm_driver, to_platform_device(dev));
@@ -597,43 +581,14 @@ static void imx_drm_unbind(struct device *dev)
 }

 static const struct component_master_ops imx_drm_ops = {
-   .add_components = imx_drm_add_components,
.bind = imx_drm_bind,
.unbind = imx_drm_unbind,
 };

-static struct imx_drm_component *imx_drm_find_component(struct device *dev,
-   struct device_node *node)
-{
-   struct imx_drm_component *component;
-
-   list_for_each_entry(component, _drm_components, list)
-   if (component->of_node == node)
-   return component;
-
-   return NULL;
-}
-
-static int imx_drm_add_component(struct device *dev, struct device_node *node)
-{
-   struct imx_drm_component *component;
-
-   if (imx_drm_find_component(dev, node))
-   return 0;
-
-   component = devm_kzalloc(dev, sizeof(*component), GFP_KERNEL);
-   if (!component)
-   return -ENOMEM;
-
-   component->of_node = node;
-   list_add_tail(>list, _drm_components);
-
-   return 0;
-}
-
 static int imx_drm_platform_probe(struct platform_device *pdev)
 {
struct device_node *ep, *port, *remote;
+   struct component_match *match = NULL;
int ret;
int i;

@@ -647,9 +602,7 @@ static int imx_drm_platform_probe(struct platform_device 
*pdev)
if (!port)
break;

-   ret = imx_drm_add_component(>dev, port);
-   if (ret < 0)
-   return ret;
+   component_match_add(>dev, , compare_of, port);
}

if (i == 0) {
@@ -675,10 +628,8 @@ static int imx_drm_platform_probe(struct platform_device 
*pdev)
continue;
}

-   ret = imx_drm_add_component(>dev, remote);
+   component_match_add(>dev, , compare_of, 
remote);
of_node_put(remote);
-   if (ret < 0)
-   return ret;
}
of_node_put(port);
}
@@ -687,7 +638,7 @@ static int imx_drm_platform_probe(struct platform_device 
*pdev)
if (ret)
return ret;

-   return component_master_add(>dev, _drm_ops);
+   return component_master_add_with_match(>dev, _drm_ops, match);
 }

 static int imx_drm_platform_remove(struct platform_device *pdev)
-- 
1.8.3.1

[PATCH RFC v2 4/8] drm: msm: update to use component match support

[Russell King]

Update MSM's DRM driver to use the component match support rather than
add_components.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/msm/msm_drv.c | 83 ++-
 1 file changed, 35 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 0d2562fb681e..b6dc5573e445 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -905,12 +905,41 @@ static int compare_of(struct device *dev, void *data)
 {
return dev->of_node == data;
 }
+#else
+static int compare_dev(struct device *dev, void *data)
+{
+   return dev == data;
+}
+#endif
+
+static int msm_drm_bind(struct device *dev)
+{
+   return drm_platform_init(_driver, to_platform_device(dev));
+}
+
+static void msm_drm_unbind(struct device *dev)
+{
+   drm_put_dev(platform_get_drvdata(to_platform_device(dev)));
+}
+
+static const struct component_master_ops msm_drm_ops = {
+   .bind = msm_drm_bind,
+   .unbind = msm_drm_unbind,
+};
+
+/*
+ * Platform driver:
+ */

-static int msm_drm_add_components(struct device *master, struct master *m)
+static int msm_pdev_probe(struct platform_device *pdev)
 {
-   struct device_node *np = master->of_node;
+   struct component_match *match = NULL;
+#ifdef CONFIG_OF
+   /* NOTE: the CONFIG_OF case duplicates the same code as exynos or imx
+* (or probably any other).. so probably some room for some helpers
+*/
+   struct device_node *np = pdev->dev.of_node;
unsigned i;
-   int ret;

for (i = 0; ; i++) {
struct device_node *node;
@@ -919,22 +948,9 @@ static int msm_drm_add_components(struct device *master, 
struct master *m)
if (!node)
break;

-   ret = component_master_add_child(m, compare_of, node);
-   of_node_put(node);
-
-   if (ret)
-   return ret;
+   component_match_add(>dev, , compare_of, node);
}
-   return 0;
-}
 #else
-static int compare_dev(struct device *dev, void *data)
-{
-   return dev == data;
-}
-
-static int msm_drm_add_components(struct device *master, struct master *m)
-{
/* For non-DT case, it kinda sucks.  We don't actually have a way
 * to know whether or not we are waiting for certain devices (or if
 * they are simply not present).  But for non-DT we only need to
@@ -958,41 +974,12 @@ static int msm_drm_add_components(struct device *master, 
struct master *m)
return -EPROBE_DEFER;
}

-   ret = component_master_add_child(m, compare_dev, dev);
-   if (ret) {
-   DBG("could not add child: %d", ret);
-   return ret;
-   }
+   component_match_add(>dev, , compare_dev, dev);
}
-
-   return 0;
-}
 #endif

-static int msm_drm_bind(struct device *dev)
-{
-   return drm_platform_init(_driver, to_platform_device(dev));
-}
-
-static void msm_drm_unbind(struct device *dev)
-{
-   drm_put_dev(platform_get_drvdata(to_platform_device(dev)));
-}
-
-static const struct component_master_ops msm_drm_ops = {
-   .add_components = msm_drm_add_components,
-   .bind = msm_drm_bind,
-   .unbind = msm_drm_unbind,
-};
-
-/*
- * Platform driver:
- */
-
-static int msm_pdev_probe(struct platform_device *pdev)
-{
pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
-   return component_master_add(>dev, _drm_ops);
+   return component_master_add_with_match(>dev, _drm_ops, match);
 }

 static int msm_pdev_remove(struct platform_device *pdev)
-- 
1.8.3.1

[PATCH RFC v2 3/8] component: add support for component match array

[Russell King]

Add support for generating a set of component matches at master probe
time, and submitting them to the component layer.  This allows the
component layer to perform the matches internally without needing to
call into the master driver, and allows for further restructuring of
the component helper.

Signed-off-by: Russell King 
---
 drivers/base/component.c  | 119 --
 include/linux/component.h |   7 +++
 2 files changed, 123 insertions(+), 3 deletions(-)

diff --git a/drivers/base/component.c b/drivers/base/component.c
index 55813e91bf0d..bd8b4908593b 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -18,6 +18,15 @@
 #include 
 #include 

+struct component_match {
+   size_t alloc;
+   size_t num;
+   struct {
+   void *data;
+   int (*fn)(struct device *, void *);
+   } compare[0];
+};
+
 struct master {
struct list_head node;
struct list_head components;
@@ -25,6 +34,7 @@ struct master {

const struct component_master_ops *ops;
struct device *dev;
+   struct component_match *match;
 };

 struct component {
@@ -96,6 +106,34 @@ int component_master_add_child(struct master *master,
 }
 EXPORT_SYMBOL_GPL(component_master_add_child);

+static int find_components(struct master *master)
+{
+   struct component_match *match = master->match;
+   size_t i;
+   int ret = 0;
+
+   if (!match) {
+   /*
+* Search the list of components, looking for components that
+* belong to this master, and attach them to the master.
+*/
+   return master->ops->add_components(master->dev, master);
+   }
+
+   /*
+* Scan the array of match functions and attach
+* any components which are found to this master.
+*/
+   for (i = 0; i < match->num; i++) {
+   ret = component_master_add_child(master,
+match->compare[i].fn,
+match->compare[i].data);
+   if (ret)
+   break;
+   }
+   return ret;
+}
+
 /* Detach all attached components from this master */
 static void master_remove_components(struct master *master)
 {
@@ -128,7 +166,7 @@ static int try_to_bring_up_master(struct master *master,
 * Search the list of components, looking for components that
 * belong to this master, and attach them to the master.
 */
-   if (master->ops->add_components(master->dev, master)) {
+   if (find_components(master)) {
/* Failed to find all components */
ret = 0;
goto out;
@@ -186,18 +224,86 @@ static void take_down_master(struct master *master)
master_remove_components(master);
 }

-int component_master_add(struct device *dev,
-   const struct component_master_ops *ops)
+static size_t component_match_size(size_t num)
+{
+   return offsetof(struct component_match, compare[num]);
+}
+
+static struct component_match *component_match_realloc(struct device *dev,
+   struct component_match *match, size_t num)
+{
+   struct component_match *new;
+
+   if (match && match->alloc == num)
+   return match;
+
+   new = devm_kmalloc(dev, component_match_size(num), GFP_KERNEL);
+   if (!new)
+   return ERR_PTR(-ENOMEM);
+
+   if (match) {
+   memcpy(new, match, component_match_size(min(match->num, num)));
+   devm_kfree(dev, match);
+   } else {
+   new->num = 0;
+   }
+
+   new->alloc = num;
+
+   return new;
+}
+
+/*
+ * Add a component to be matched.
+ *
+ * The match array is first created or extended if necessary.
+ */
+void component_match_add(struct device *dev, struct component_match **matchptr,
+   int (*compare)(struct device *, void *), void *compare_data)
+{
+   struct component_match *match = *matchptr;
+
+   if (IS_ERR(match))
+   return;
+
+   if (!match || match->num == match->alloc) {
+   size_t new_size = match ? match->alloc + 16 : 15;
+
+   match = component_match_realloc(dev, match, new_size);
+
+   *matchptr = match;
+
+   if (IS_ERR(match))
+   return;
+   }
+
+   match->compare[match->num].fn = compare;
+   match->compare[match->num].data = compare_data;
+   match->num++;
+}
+
+int component_master_add_with_match(struct device *dev,
+   const struct component_master_ops *ops,
+   struct component_match *match)
 {
struct master *master;
int ret;

+   if (ops->add_components && match)
+   return -EINVAL;
+
+   /* Reallocate the match array for its true size */
+   match = component_match_realloc(dev, match, match->num);
+   if (IS_ERR(match))
+

[PATCH RFC v2 2/8] component: ignore multiple additions of the same component

[Russell King]

Permit masters to call component_master_add_child() and match the same
child multiple times.  This may happen if there's multiple connections
to a single component device from other devices.  In such scenarios,
we should not return a failure, but instead ignore the attempt.

Signed-off-by: Russell King 
---
 drivers/base/component.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/base/component.c b/drivers/base/component.c
index d0ebd4431736..55813e91bf0d 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -69,6 +69,11 @@ static void component_detach_master(struct master *master, 
struct component *c)
c->master = NULL;
 }

+/*
+ * Add a component to a master, finding the component via the compare
+ * function and compare data.  This is safe to call for duplicate matches
+ * and will not result in the same component being added multiple times.
+ */
 int component_master_add_child(struct master *master,
int (*compare)(struct device *, void *), void *compare_data)
 {
@@ -76,11 +81,12 @@ int component_master_add_child(struct master *master,
int ret = -ENXIO;

list_for_each_entry(c, _list, node) {
-   if (c->master)
+   if (c->master && c->master != master)
continue;

if (compare(c->dev, compare_data)) {
-   component_attach_master(master, c);
+   if (!c->master)
+   component_attach_master(master, c);
ret = 0;
break;
}
-- 
1.8.3.1

[PATCH RFC v2 1/8] component: fix missed cleanup in case of devres failure

[Russell King]

In try_to_bring_up_master(), we tear down the master's component list
for each error case, except for devres group failure.  Fix this
oversight by making the code less prone to such mistakes.

Signed-off-by: Russell King 
---
 drivers/base/component.c | 62 
 1 file changed, 31 insertions(+), 31 deletions(-)

diff --git a/drivers/base/component.c b/drivers/base/component.c
index c4778995cd72..d0ebd4431736 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -113,44 +113,44 @@ static void master_remove_components(struct master 
*master)
 static int try_to_bring_up_master(struct master *master,
struct component *component)
 {
-   int ret = 0;
+   int ret;

-   if (!master->bound) {
-   /*
-* Search the list of components, looking for components that
-* belong to this master, and attach them to the master.
-*/
-   if (master->ops->add_components(master->dev, master)) {
-   /* Failed to find all components */
-   master_remove_components(master);
-   ret = 0;
-   goto out;
-   }
+   if (master->bound)
+   return 0;

-   if (component && component->master != master) {
-   master_remove_components(master);
-   ret = 0;
-   goto out;
-   }
+   /*
+* Search the list of components, looking for components that
+* belong to this master, and attach them to the master.
+*/
+   if (master->ops->add_components(master->dev, master)) {
+   /* Failed to find all components */
+   ret = 0;
+   goto out;
+   }

-   if (!devres_open_group(master->dev, NULL, GFP_KERNEL)) {
-   ret = -ENOMEM;
-   goto out;
-   }
+   if (component && component->master != master) {
+   ret = 0;
+   goto out;
+   }

-   /* Found all components */
-   ret = master->ops->bind(master->dev);
-   if (ret < 0) {
-   devres_release_group(master->dev, NULL);
-   dev_info(master->dev, "master bind failed: %d\n", ret);
-   master_remove_components(master);
-   goto out;
-   }
+   if (!devres_open_group(master->dev, NULL, GFP_KERNEL)) {
+   ret = -ENOMEM;
+   goto out;
+   }

-   master->bound = true;
-   ret = 1;
+   /* Found all components */
+   ret = master->ops->bind(master->dev);
+   if (ret < 0) {
+   devres_release_group(master->dev, NULL);
+   dev_info(master->dev, "master bind failed: %d\n", ret);
+   goto out;
}
+
+   master->bound = true;
+   return 1;
+
 out:
+   master_remove_components(master);

return ret;
 }
-- 
1.8.3.1

[PATCH RFC v2 0/8] component helper improvements

[Russell King - ARM Linux]

A while back, Laurent raised some comments about the component helper,
which this patch set starts to address.

The first point it addresses is the repeated parsing inefficiency when
deferred probing occurs.  When DT is used, the structure of the
component helper today means that masters end up parsing the device
tree for each attempt to re-bind the driver.

We remove this inefficiency by creating an array of matching data and
functions, which the component helper can use internally to match up
components to their master.

The second point was the inefficiency of destroying the list of
components each time we saw a failure.  We did this to ensure that
we kept things correctly ordered: component bind order matters.
As we have an array instead, the array is already ordered, so we
use this array to store the component pointers instead of a list,
and remember which are duplicates (and thus should be avoided.)
Avoiding the right duplicates matters as we walk the array in the
opposite direction at tear down.

 drivers/base/component.c   | 249 ++---
 drivers/gpu/drm/msm/msm_drv.c  |  83 +--
 drivers/staging/imx-drm/imx-drm-core.c |  57 +---
 include/linux/component.h  |   8 +-
 4 files changed, 208 insertions(+), 189 deletions(-)

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

[PATCH v2 2/3] drm/ttm: introduce dma cache sync helpers

[Alexandre Courbot]

On 06/24/2014 07:33 PM, Alexandre Courbot wrote:
> On 06/24/2014 07:02 PM, Russell King - ARM Linux wrote:
>> On Tue, Jun 24, 2014 at 06:54:26PM +0900, Alexandre Courbot wrote:
>>> From: Lucas Stach 
>>>
>>> On architectures for which access to GPU memory is non-coherent,
>>> caches need to be flushed and invalidated explicitly at the
>>> appropriate places. Introduce two small helpers to make things
>>> easy for TTM-based drivers.
>>
>> Have you run this with DMA API debugging enabled?  I suspect you haven't,
>> and I recommend that you do.
>
> # cat /sys/kernel/debug/dma-api/error_count
> 162621
>
> (??? ???)

*puts table back on its feet*

So, yeah - TTM memory is not allocated using the DMA API, hence we 
cannot use the DMA API to sync it. Thanks Russell for pointing it out.

The only alternative I see here is to flush the CPU caches when syncing 
for the device, and invalidate them for the other direction. Of course 
if the device has caches on its side as well the opposite operation must 
also be done for it. Guess the only way is to handle it all by ourselves 
here. :/

[PATCH v2 2/3] drm/ttm: introduce dma cache sync helpers

[Alexandre Courbot]

On 06/24/2014 07:02 PM, Russell King - ARM Linux wrote:
> On Tue, Jun 24, 2014 at 06:54:26PM +0900, Alexandre Courbot wrote:
>> From: Lucas Stach 
>>
>> On architectures for which access to GPU memory is non-coherent,
>> caches need to be flushed and invalidated explicitly at the
>> appropriate places. Introduce two small helpers to make things
>> easy for TTM-based drivers.
>
> Have you run this with DMA API debugging enabled?  I suspect you haven't,
> and I recommend that you do.

# cat /sys/kernel/debug/dma-api/error_count
162621

(??? ???)

[PATCH 1/2] Revert "drm/radeon: remove drm_vblank_get|put from pflip handling"

[Michel Dänzer]

On 24.06.2014 05:32, Dieter N?tzel wrote:
> Am 23.06.2014 21:46, schrieb Dieter N?tzel:
>> Am 23.06.2014 11:34, schrieb Michel D?nzer:
>>> On 18.06.2014 18:14, Christian K?nig wrote:
 Am 18.06.2014 07:53, schrieb Michel D?nzer:
>
>   (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip completion
> event has impossible msc [x-1] < target_msc [x]
>
> messages in the X log file which have been popping up in bug reports
> lately.
> This also results in 0s being returned to the client for the MSC and
> timestamp of the swap completion, which could cause all kinds of bad
> behaviour.
 First of all thanks for looking into it. Are you getting this on
 3.16 or
 3.15?
>>>
>>> I haven't actually run into this myself yet. I thought I'd seen it in
>>> several bug reports, but right now I can only find
>>> https://bugs.freedesktop.org/show_bug.cgi?id=80029#c17 , which seems to
>>> include the page flipping changes from 3.16.
>>
>> With 3.16-rc2 I get it now on my RV730 AGP as in the above bug report.
>> But only the lines in Xorg.0.log.
>> NO signs of any damage/error in use.
>>
>> Since 3.15 and 3.16 (rc2 only) my system is rock solid.
>>
>> I've tried 3.15-rc7 + Christian's pflip rework (did some little
>> handwork), too.
>> It was solid but I saw the reported flip/black distortion in the below
>> part during Kwin 4.13 cube screen effect (rotation). Your fix for
>> 3.16-rc1 fixed that.

That's good to hear.


> I can reliable generate such lines in Xorg.0.log with KWin cube desktop
> effect.
> 
> Rotate screens with mouse wheel or screen switcher => new entry in
> Xorg.0.log. If it happens I notice ('see') flip delay.

I was only able to reproduce it a couple of times even with that, but not
at all yet with the patch below. Does it help for you as well?


 I don't think that the pflip irq is thrown earlier than the vblank, but
 on 3.16 it might actually be that we program the flip so fast into the
 hardware that we do it one frame earlier than planned.
>>>
>>> So userspace is notified of the previous vertical blank period and calls
>>> the page flip ioctl in response, which then manages to program the
>>> scanout address update into the hardware before the scanout address
>>> update is latched during the previous vertical blank period?

I think there's another possible scenario:

 1. Userspace submits page flip intended for MSC x
 2. The vertical blank interrupt is triggered for MSC x =>
radeon_crtc_handle_vblank() => radeon_crtc_handle_flip()
 3. Userspace submits page flip intended for MSC (x + 1)
 4. The page flip interrupt is triggered for the previous flip =>
radeon_crtc_handle_flip() => drm_send_vblank_event(). The second flip
hasn't actually executed yet, and the event has MSC x instead of (x + 1)
as expected by userspace.

If that is the case, only actually enabling and handling the page flip
interrupt when a flip is pending might also avoid it. I can hack that up
tomorrow, if Christian doesn't beat me to it.


diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
b/drivers/gpu/drm/radeon/radeon_display.c
index 8b575a4..8350f8c 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -336,14 +336,19 @@ void radeon_crtc_handle_flip(struct radeon_device *rdev, 
int crtc_id)
struct radeon_crtc *radeon_crtc = rdev->mode_info.crtcs[crtc_id];
struct radeon_flip_work *work;
unsigned long flags;
+   struct timeval vblank_time;
+   u32 vblank_seq;

/* this can happen at init */
if (radeon_crtc == NULL)
return;

+   vblank_seq = drm_vblank_count_and_time(rdev->ddev, crtc_id, 
_time);
+
spin_lock_irqsave(>ddev->event_lock, flags);
work = radeon_crtc->flip_work;
-   if (work == NULL) {
+   if (work == NULL ||
+   (vblank_seq - work->event->event.sequence) > (1<<23)) {
spin_unlock_irqrestore(>ddev->event_lock, flags);
return;
}
@@ -379,6 +384,7 @@ static void radeon_flip_work_func(struct work_struct 
*__work)

struct drm_crtc *crtc = _crtc->base;
struct drm_framebuffer *fb = work->fb;
+   struct timeval vblank_time;

uint32_t tiling_flags, pitch_pixels;
uint64_t base;
@@ -466,6 +472,10 @@ static void radeon_flip_work_func(struct work_struct 
*__work)
goto pflip_cleanup;
}

+   work->event->event.sequence =
+   drm_vblank_count_and_time(crtc->dev, radeon_crtc->crtc_id,
+ _time) + 1;
+
/* We borrow the event spin lock for protecting flip_work */
spin_lock_irqsave(>dev->event_lock, flags);



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

[PATCH v2 3/3] drm/nouveau: hook up cache sync functions

[Alexandre Courbot]

From: Lucas Stach 

Use the newly-introduced TTM cache sync functions in Nouveau.

Signed-off-by: Lucas Stach 
[acourbot at nvidia.com: rearrange code, make platform-friendly]
Signed-off-by: Alexandre Courbot 
---
 drivers/gpu/drm/nouveau/nouveau_bo.c  | 47 +++
 drivers/gpu/drm/nouveau/nouveau_bo.h  |  1 +
 drivers/gpu/drm/nouveau/nouveau_gem.c | 10 +++-
 3 files changed, 51 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index b6dc85c614be..74c68c16e777 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -284,6 +284,34 @@ set_placement_range(struct nouveau_bo *nvbo, uint32_t type)
}
 }

+static void
+nouveau_bo_sync_for_cpu(struct nouveau_bo *nvbo)
+{
+   struct nouveau_device *device;
+   struct ttm_tt *ttm = nvbo->bo.ttm;
+
+   device = nouveau_dev(nouveau_bdev(ttm->bdev)->dev);
+
+   if (nvbo->bo.ttm && nvbo->bo.ttm->caching_state == tt_cached)
+   ttm_dma_tt_cache_sync_for_cpu((struct ttm_dma_tt *)nvbo->bo.ttm,
+ nv_device_base(device));
+}
+
+static void
+nouveau_bo_sync_for_device(struct nouveau_bo *nvbo)
+{
+   struct ttm_tt *ttm = nvbo->bo.ttm;
+
+   if (ttm && ttm->caching_state == tt_cached) {
+   struct nouveau_device *device;
+
+   device = nouveau_dev(nouveau_bdev(ttm->bdev)->dev);
+
+   ttm_dma_tt_cache_sync_for_device((struct ttm_dma_tt *)ttm,
+nv_device_base(device));
+   }
+}
+
 void
 nouveau_bo_placement_set(struct nouveau_bo *nvbo, uint32_t type, uint32_t busy)
 {
@@ -407,6 +435,8 @@ nouveau_bo_validate(struct nouveau_bo *nvbo, bool 
interruptible,
 {
int ret;

+   nouveau_bo_sync_for_device(nvbo);
+
ret = ttm_bo_validate(>bo, >placement,
  interruptible, no_wait_gpu);
if (ret)
@@ -415,6 +445,23 @@ nouveau_bo_validate(struct nouveau_bo *nvbo, bool 
interruptible,
return 0;
 }

+int
+nouveau_bo_wait(struct nouveau_bo *nvbo, bool no_wait)
+{
+   int ret;
+
+   spin_lock(>bo.bdev->fence_lock);
+   ret = ttm_bo_wait(>bo, true, true, no_wait);
+   spin_unlock(>bo.bdev->fence_lock);
+
+   if (ret)
+   return ret;
+
+   nouveau_bo_sync_for_cpu(nvbo);
+
+   return 0;
+}
+
 u16
 nouveau_bo_rd16(struct nouveau_bo *nvbo, unsigned index)
 {
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.h 
b/drivers/gpu/drm/nouveau/nouveau_bo.h
index ff17c1f432fc..a4e9052d54fd 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.h
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.h
@@ -81,6 +81,7 @@ void nouveau_bo_wr32(struct nouveau_bo *, unsigned index, u32 
val);
 void nouveau_bo_fence(struct nouveau_bo *, struct nouveau_fence *);
 int  nouveau_bo_validate(struct nouveau_bo *, bool interruptible,
 bool no_wait_gpu);
+int nouveau_bo_wait(struct nouveau_bo *, bool no_wait);

 struct nouveau_vma *
 nouveau_bo_vma_find(struct nouveau_bo *, struct nouveau_vm *);
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c 
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index c90c0dc0afe8..916cb8ff568c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -884,19 +884,15 @@ nouveau_gem_ioctl_cpu_prep(struct drm_device *dev, void 
*data,
 {
struct drm_nouveau_gem_cpu_prep *req = data;
struct drm_gem_object *gem;
-   struct nouveau_bo *nvbo;
bool no_wait = !!(req->flags & NOUVEAU_GEM_CPU_PREP_NOWAIT);
-   int ret = -EINVAL;
+   int ret;

gem = drm_gem_object_lookup(dev, file_priv, req->handle);
if (!gem)
return -ENOENT;
-   nvbo = nouveau_gem_object(gem);
-
-   spin_lock(>bo.bdev->fence_lock);
-   ret = ttm_bo_wait(>bo, true, true, no_wait);
-   spin_unlock(>bo.bdev->fence_lock);
+   ret = nouveau_bo_wait(nouveau_gem_object(gem), no_wait);
drm_gem_object_unreference_unlocked(gem);
+
return ret;
 }

-- 
2.0.0

[PATCH v2 2/3] drm/ttm: introduce dma cache sync helpers

[Alexandre Courbot]

From: Lucas Stach 

On architectures for which access to GPU memory is non-coherent,
caches need to be flushed and invalidated explicitly at the
appropriate places. Introduce two small helpers to make things
easy for TTM-based drivers.

Signed-off-by: Lucas Stach 
Signed-off-by: Alexandre Courbot 
---
 drivers/gpu/drm/ttm/ttm_tt.c| 25 +
 include/drm/ttm/ttm_bo_driver.h | 28 
 2 files changed, 53 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 75f319090043..66c16ad35f70 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -38,6 +38,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -248,6 +249,30 @@ void ttm_dma_tt_fini(struct ttm_dma_tt *ttm_dma)
 }
 EXPORT_SYMBOL(ttm_dma_tt_fini);

+void ttm_dma_tt_cache_sync_for_device(struct ttm_dma_tt *ttm_dma,
+ struct device *dev)
+{
+   unsigned long i;
+
+   for (i = 0; i < ttm_dma->ttm.num_pages; i++) {
+   dma_sync_single_for_device(dev, ttm_dma->dma_address[i],
+  PAGE_SIZE, DMA_TO_DEVICE);
+   }
+}
+EXPORT_SYMBOL(ttm_dma_tt_cache_sync_for_device);
+
+void ttm_dma_tt_cache_sync_for_cpu(struct ttm_dma_tt *ttm_dma,
+  struct device *dev)
+{
+   unsigned long i;
+
+   for (i = 0; i < ttm_dma->ttm.num_pages; i++) {
+   dma_sync_single_for_cpu(dev, ttm_dma->dma_address[i],
+   PAGE_SIZE, DMA_FROM_DEVICE);
+   }
+}
+EXPORT_SYMBOL(ttm_dma_tt_cache_sync_for_cpu);
+
 void ttm_tt_unbind(struct ttm_tt *ttm)
 {
int ret;
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index a5183da3ef92..52fb709568fc 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -41,6 +41,7 @@
 #include 
 #include 
 #include 
+#include 

 struct ttm_backend_func {
/**
@@ -690,6 +691,33 @@ extern int ttm_tt_swapout(struct ttm_tt *ttm,
  */
 extern void ttm_tt_unpopulate(struct ttm_tt *ttm);

+/**
+ * ttm_dma_tt_cache_sync_for_device:
+ *
+ * @ttm A struct ttm_tt of the type returned by ttm_dma_tt_init.
+ * @dev A struct device representing the device to which to sync.
+ *
+ * This function will flush the CPU caches on arches where snooping in the
+ * TT is not available. On fully coherent arches this will turn into an 
(almost)
+ * noop. This makes sure that data written by the CPU is visible to the device.
+ */
+extern void ttm_dma_tt_cache_sync_for_device(struct ttm_dma_tt *ttm_dma,
+struct device *dev);
+
+/**
+ * ttm_dma_tt_cache_sync_for_cpu:
+ *
+ * @ttm A struct ttm_tt of the type returned by ttm_dma_tt_init.
+ * @dev A struct device representing the device from which to sync.
+ *
+ * This function will invalidate the CPU caches on arches where snooping in the
+ * TT is not available. On fully coherent arches this will turn into an 
(almost)
+ * noop. This makes sure that the CPU does not read any stale cached or
+ * prefetched data.
+ */
+extern void ttm_dma_tt_cache_sync_for_cpu(struct ttm_dma_tt *ttm_dma,
+ struct device *dev);
+
 /*
  * ttm_bo.c
  */
-- 
2.0.0

[PATCH v2 1/3] drm/ttm: recognize ARM arch in ioprot handler

[Alexandre Courbot]

From: Lucas Stach 

Signed-off-by: Lucas Stach 
Signed-off-by: Alexandre Courbot 
---
 drivers/gpu/drm/ttm/ttm_bo_util.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 1df856f78568..30e5d90cb7bc 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -500,7 +500,7 @@ pgprot_t ttm_io_prot(uint32_t caching_flags, pgprot_t tmp)
pgprot_val(tmp) |= _PAGE_GUARDED;
}
 #endif
-#if defined(__ia64__)
+#if defined(__ia64__) || defined(__arm__)
if (caching_flags & TTM_PL_FLAG_WC)
tmp = pgprot_writecombine(tmp);
else
-- 
2.0.0

[PATCH v2 0/3] drm/ttm: nouveau: memory coherency for ARM

[Alexandre Courbot]

For this v2 I have fixed the patches that are non-controversial (all Lucas' :))
and am resubmitting them in the hope that they will get merged. This will
just leave the issue of Nouveau system-memory buffers mapping to be solved.

This issue is quite complex, so let me summarize the situation and the data
I have at hand. ARM caching is like a quantum world where Murphy's law
constantly applies: sometimes things that you don't expect to work happen to
work, but never the ones you would like to.

On ARM the accepted wisdom is that all CPU mappings must share the same
attributes, and that failure to do so results in undefined behavior. I have
heard voices claiming that recent ARM SoCs were not affected by this, but have
yet to see hard evidence that it is indeed the case.

Most (or all) physical memory happens to be already mapped, cached, in the
lowmem area of the virtual address space. This means that if we want to be
safe wrt. the rule mentioned above, we must perform all subsequent memory
mappings the same way.

Nouveau currently performs its memory mappings cached, since it can rely on PCI
to snoop and invalidate addresses written by the CPU - something that we don't
have on ARM shared-memory systems. I had proposed a (bad) patch in the previous
revision of this series that added a way to flush the CPU cache after each write
(http://lists.freedesktop.org/archives/dri-devel/2014-May/059893.html ) but it
did not trigger a lot of approval. Instead, it has been suggested to map such
BOs write-combined.

This would break the "one mapping type only" rule, but I gave it a try by
changing the TTM_PL_TT manager's authorized caching to WC. This immediatly
resulted in breakage of applications using the GPU. Digging a little further,
I noticed that kernel mappings could be performed WC or uncached without any
problem, but that user-space mappings *must* be cached under all circumstances.
Failure to do so results in invalid pushbuffers being sent to the GPUs, messed
up vertices, and other corruptions. Uncached mappings result in the same
breakage.

So, to summarize our options for GK20A:
1) Keeping mappings of TTM buffers cached seems to be the safest option, as it
is consistent with the lowmem mapping likely affecting the memory of our
buffers. But we will have to flush kernel CPU writes to these buffers one way
or the other.
2) Changing the kernel mappings to WC or uncached seems to be safe. However
user-space mappings must still be cached or inconsistencies happen. This
double-policy for kernel and user-space mappings is not implemented in TTM
and nothing so far suggests that it should be.

And that's the state where we are. I am not considering the other possibilities
(carving memory out of lowmem, etc.) as they have already been discussed many
times by people much smarter than me (e.g. 
http://lists.linaro.org/pipermail/linaro-mm-sig/2011-April/03.html )
and it seems that the issue is still here nonetheless.

At this point suggestions towards option 1) or 2) (or where I could have
screwed up in my understanding of ARM mappings) are welcome. And in the
meantime, let's try to get the 3 guys below merged!

Changes since v1:
- Removed conditional compilation for Nouveau cache sync handler
- Refactored nouveau_gem_ioctl_cpu_prep() into a new function to keep buffer
  cache management into nouveau_bo.c

Lucas Stach (3):
  drm/ttm: recognize ARM arch in ioprot handler
  drm/ttm: introduce dma cache sync helpers
  drm/nouveau: hook up cache sync functions

 drivers/gpu/drm/nouveau/nouveau_bo.c  | 47 +++
 drivers/gpu/drm/nouveau/nouveau_bo.h  |  1 +
 drivers/gpu/drm/nouveau/nouveau_gem.c | 10 +++-
 drivers/gpu/drm/ttm/ttm_bo_util.c |  2 +-
 drivers/gpu/drm/ttm/ttm_tt.c  | 25 +++
 include/drm/ttm/ttm_bo_driver.h   | 28 +
 6 files changed, 105 insertions(+), 8 deletions(-)

-- 
2.0.0

[PATCH v14 04/10] imx-drm: use defines for clock polarity settings

[Denis Carikli]

On 06/24/2014 05:13 PM, Russell King - ARM Linux wrote:
[...]
> If you'd like to send me better commit messages for
> these patches, I'll add them to what I already have:

>   imx-drm: use defines for clock polarity settings
The comment of the clk_pol field of the ipu_di_signal_cfg struct was 
inverted.
Instead of merely inverting the comment, the values of clk_pol were defined.

>   imx-drm: add RGB666 support for parallel display.
This permits to drive parallel displays that expect the RGB666 color format.
>
> It may also be worth describing the RGB666 format in the commit message
> for:
>
>   v4l2: add new V4L2_PIX_FMT_RGB666 pixel format.
The RGB666 color format encodes 6 bits for each color(red, green and 
blue), linearly.
It looks like this in memory:
017
RRGGBB

Denis.

[Bug 80141] Fails to page flip multiple time, queue overflows waiting for one to finish that never does crashing entire system.

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

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

--- Comment #9 from Aaron B  ---
(In reply to comment #8)
> (In reply to comment #7)
> > With 3.15 or newer, might be worth trying the patches from
> > http://lists.freedesktop.org/archives/dri-devel/2014-June/062245.html .
> 
> Don't bother trying those patches just yet, they don't seem to be working
> yet.

Okay no problem. I just had a crash happen and recover. What commands should I
run to get any useful log information for this? I'd post more logs, but it'd
just be more of the same basically. I'll fall back down to 3.13 for now and try
to get it to occur.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140624/badc9fd4/attachment.html>

[Bug 80419] XCOM: Enemy Unknown Causes lockup

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

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

--- Comment #12 from theamazingjanet at googlemail.com ---
Created attachment 101680
  --> https://bugs.freedesktop.org/attachment.cgi?id=101680=edit
X log.old

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140624/6aacf143/attachment.html>

[Bug 80419] XCOM: Enemy Unknown Causes lockup

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

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

--- Comment #11 from theamazingjanet at googlemail.com ---
(In reply to comment #7)
> Any chance you could try an LLVM 3.5 snapshot?
> 
> Also, if you could log in via ssh and grab dmesg after the problem occurs,
> that might be interesting.

I don't have a second machine of my own setup to try it from but I'll see what
I can do. For now, Xorg.0.log.old seems to better match up with the time of the
error, and shows a mumber of EQ overflow errors that aren't in Xorg.0.log.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140624/bc05ccec/attachment.html>

[PATCH/RESEND 1/9] drm/i2c: tda998x: move drm_i2c_encoder_destroy call

[Russell King - ARM Linux]

On Tue, Jun 17, 2014 at 11:17:03AM -0300, Guido Mart?nez wrote:
> Currently tda998x_encoder_destroy() calls cec_write() and reg_clear(),
> as part of the release procedure. Such calls need to access the I2C bus
> and therefore, we need to call them before drm_i2c_encoder_destroy()
> which unregisters the I2C device.
> 
> This commit moves the latter so it's done afterwards.
> 
> Signed-off-by: Guido Mart?nez 
> Signed-off-by: Ezequiel Garc?a 
> Cc:  #v3.9+

You really should have sent this with me in the To: header as I'm now the
maintainer of this driver.  Yes, this is a valid fix, and I'll apply it
shortly.  Thanks.

> ---
>  drivers/gpu/drm/i2c/tda998x_drv.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
> b/drivers/gpu/drm/i2c/tda998x_drv.c
> index 240c331..db9515f 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -1183,7 +1183,6 @@ static void
>  tda998x_encoder_destroy(struct drm_encoder *encoder)
>  {
>   struct tda998x_priv *priv = to_tda998x_priv(encoder);
> - drm_i2c_encoder_destroy(encoder);
>  
>   /* disable all IRQs and free the IRQ handler */
>   cec_write(priv, REG_CEC_RXSHPDINTENA, 0);
> @@ -1193,6 +1192,7 @@ tda998x_encoder_destroy(struct drm_encoder *encoder)
>  
>   if (priv->cec)
>   i2c_unregister_device(priv->cec);
> + drm_i2c_encoder_destroy(encoder);
>   kfree(priv);
>  }
>  
> -- 
> 2.0.0
> 

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

[PATCH v14 04/10] imx-drm: use defines for clock polarity settings

[Russell King - ARM Linux]

On Tue, Jun 24, 2014 at 06:25:19PM +0200, Denis Carikli wrote:
> On 06/24/2014 05:13 PM, Russell King - ARM Linux wrote:
> [...]
>> If you'd like to send me better commit messages for
>> these patches, I'll add them to what I already have:
>
>>  imx-drm: use defines for clock polarity settings
> The comment of the clk_pol field of the ipu_di_signal_cfg struct was  
> inverted.
> Instead of merely inverting the comment, the values of clk_pol were defined.

s/inverting/fixing/

>
>>  imx-drm: add RGB666 support for parallel display.
> This permits to drive parallel displays that expect the RGB666 color format.

This allows imx-drm to drive ...

>>
>> It may also be worth describing the RGB666 format in the commit message
>> for:
>>
>>  v4l2: add new V4L2_PIX_FMT_RGB666 pixel format.
> The RGB666 color format encodes 6 bits for each color(red, green and  
> blue), linearly.
> It looks like this in memory:
> 017
> RRGGBB

Thanks! I've tweaked them very slightly as detailed above so they read a
bit better.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

[Bug 80419] XCOM: Enemy Unknown Causes lockup

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

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

--- Comment #10 from Sylvain BERTRAND  ---
I stand corrected: Got the lockup and crash in the middle of a mission.

up-to-date x86_64 fedora rawhide. Tahiti XT.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140624/4f1b4101/attachment.html>

[PATCH/RESEND 8/9] drm/tilcdc: remove submodule destroy calls

[Darren Etheridge]

Guido,

On 06/17/2014 09:17 AM, Guido Mart?nez wrote:
> The TI tilcdc driver is designed with a notion of submodules. Currently,
> at unload time, these submodules are iterated and destroyed.
>
> Now that the tilcdc remove order is fixed, this can be handled perfectly

I am not sure I understand the first part of the above sentence - did 
something change with tilcdc ordering?  I think you a referring to 
previous patches in your series which really mean tilcdc can actually 
unload now.  So really the method this patch uses could always have been 
used, it just wasn't for some reason?

I have tested all of the other patches in your series and all looks good 
on BeagleBone Black and AM335xEVM, I tested as both built-ins and 
modules and can load/unload on BeagleBone Black with HDMI enabled correctly.

I want to play around a bit more with this particular patch, to try and 
understand how it differs from Rob's original intent with his module 
registration/deregistration scheme.  I prefer your method, but do we 
loose anything that Rob's originally had in mind?

Darren

> by the kernel using the device infrastructure, since each submodule
> is a kernel driver itself, and they are only destroy()'ed at unload
> time. Therefore we move the destroy() functionality to each submodule's
> remove().
>
> Also, remove some checks in the unloading process since the new code
> guarantees the resources are allocated and need a release.
>
> Signed-off-by: Guido Mart?nez 
> ---
>   drivers/gpu/drm/tilcdc/Module.symvers  |  0
>   drivers/gpu/drm/tilcdc/tilcdc_drv.c|  6 --
>   drivers/gpu/drm/tilcdc/tilcdc_drv.h|  1 -
>   drivers/gpu/drm/tilcdc/tilcdc_panel.c  | 36 
> +-
>   drivers/gpu/drm/tilcdc/tilcdc_slave.c  | 26 +---
>   drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 34 
>   6 files changed, 50 insertions(+), 53 deletions(-)
>   create mode 100644 drivers/gpu/drm/tilcdc/Module.symvers
>
> diff --git a/drivers/gpu/drm/tilcdc/Module.symvers 
> b/drivers/gpu/drm/tilcdc/Module.symvers
> new file mode 100644
> index 000..e69de29
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> index 006a30e..2c860c4 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> @@ -120,7 +120,6 @@ static int cpufreq_transition(struct notifier_block *nb,
>   static int tilcdc_unload(struct drm_device *dev)
>   {
>   struct tilcdc_drm_private *priv = dev->dev_private;
> - struct tilcdc_module *mod, *cur;
>
>   drm_fbdev_cma_fini(priv->fbdev);
>   drm_kms_helper_poll_fini(dev);
> @@ -149,11 +148,6 @@ static int tilcdc_unload(struct drm_device *dev)
>
>   pm_runtime_disable(dev->dev);
>
> - list_for_each_entry_safe(mod, cur, _list, list) {
> - DBG("destroying module: %s", mod->name);
> - mod->funcs->destroy(mod);
> - }
> -
>   kfree(priv);
>
>   return 0;
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.h 
> b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
> index 0938036..7596c14 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
> @@ -98,7 +98,6 @@ struct tilcdc_module;
>   struct tilcdc_module_ops {
>   /* create appropriate encoders/connectors: */
>   int (*modeset_init)(struct tilcdc_module *mod, struct drm_device *dev);
> - void (*destroy)(struct tilcdc_module *mod);
>   #ifdef CONFIG_DEBUG_FS
>   /* create debugfs nodes (can be NULL): */
>   int (*debugfs_init)(struct tilcdc_module *mod, struct drm_minor *minor);
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
> index b085dcc..2f6efae 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
> @@ -282,21 +282,8 @@ static int panel_modeset_init(struct tilcdc_module *mod, 
> struct drm_device *dev)
>   return 0;
>   }
>
> -static void panel_destroy(struct tilcdc_module *mod)
> -{
> - struct panel_module *panel_mod = to_panel_module(mod);
> -
> - if (panel_mod->timings)
> - display_timings_release(panel_mod->timings);
> -
> - tilcdc_module_cleanup(mod);
> - kfree(panel_mod->info);
> - kfree(panel_mod);
> -}
> -
>   static const struct tilcdc_module_ops panel_module_ops = {
>   .modeset_init = panel_modeset_init,
> - .destroy = panel_destroy,
>   };
>
>   /*
> @@ -372,6 +359,7 @@ static int panel_probe(struct platform_device *pdev)
>   return -ENOMEM;
>
>   mod = _mod->base;
> + pdev->dev.platform_data = mod;
>
>   tilcdc_module_init(mod, "panel", _module_ops);
>
> @@ -379,17 +367,16 @@ static int panel_probe(struct platform_device *pdev)
>   if (IS_ERR(pinctrl))
>   dev_warn(>dev, "pins are not configured\n");
>
> -
>   panel_mod->timings = of_get_display_timings(node);
>   if (!panel_mod->timings) {
>   

[PATCH/RESEND 9/9] drm/tilcdc: replace late_initcall with module_init

[Darren Etheridge]

On 06/17/2014 09:17 AM, Guido Mart?nez wrote:
> Use module_init instead of late_initcall, as is the norm for modular
> drivers.
>
> module_init was used until 6e8de0bd6a51fdeebd5d975c4fcc426f730b339b
> ("drm/tilcdc: add encoder slave (v2)") changed it to a late_initcall,
> but it does not explain why. Tests show it's working properly with
> module_init.
>

If I recall, the late_initcall stuff was done to try and make sure the 
tda998x/i2c subsystem came up before tilcdc. However it didn't always 
work so we added commit: 39de6194131c155901f96686a063212656d80c2e to try 
and ensure the ordering.  This might be why changing back to module_init 
is fine (and I agree with your assessment from my testing).

> Signed-off-by: Guido Mart?nez 
> ---
>   drivers/gpu/drm/tilcdc/tilcdc_drv.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> index 2c860c4..6be623b 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> @@ -629,7 +629,7 @@ static void __exit tilcdc_drm_fini(void)
>   tilcdc_tfp410_fini();
>   }
>
> -late_initcall(tilcdc_drm_init);
> +module_init(tilcdc_drm_init);
>   module_exit(tilcdc_drm_fini);
>
>   MODULE_AUTHOR("Rob Clark 

[PATCH] drm/exynos: Support DP CLKCON register in FIMD driver

[Ajay Kumar]

Add the missing setting for DP CLKCON register.

This register is present on Exynos5 based FIMD controllers,
and needs to be used if we are using DP.

Signed-off-by: Ajay Kumar 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |5 +
 include/video/samsung_fimd.h |4 
 2 files changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 33161ad..5d3045d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -72,6 +72,7 @@ struct fimd_driver_data {
unsigned int has_shadowcon:1;
unsigned int has_clksel:1;
unsigned int has_limited_fmt:1;
+   unsigned int has_dp_clkcon:1;
 };

 static struct fimd_driver_data s3c64xx_fimd_driver_data = {
@@ -88,6 +89,7 @@ static struct fimd_driver_data exynos4_fimd_driver_data = {
 static struct fimd_driver_data exynos5_fimd_driver_data = {
.timing_base = 0x2,
.has_shadowcon = 1,
+   .has_dp_clkcon = 1,
 };

 struct fimd_win_data {
@@ -331,6 +333,9 @@ static void fimd_commit(struct exynos_drm_manager *mgr)
if (clkdiv > 1)
val |= VIDCON0_CLKVAL_F(clkdiv - 1) | VIDCON0_CLKDIR;

+   if (ctx->driver_data->has_dp_clkcon)
+   writel(DP_CLK_ENABLE, ctx->regs + DP_CLKCON);
+
writel(val, ctx->regs + VIDCON0);
 }

diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
index b039320..d8f4b0b 100644
--- a/include/video/samsung_fimd.h
+++ b/include/video/samsung_fimd.h
@@ -435,6 +435,10 @@
 #define BLENDCON_NEW_8BIT_ALPHA_VALUE  (1 << 0)
 #define BLENDCON_NEW_4BIT_ALPHA_VALUE  (0 << 0)

+/* Video clock enable for DP */
+#define DP_CLKCON  0x27C
+#define DP_CLK_ENABLE  0x2
+
 /* Notes on per-window bpp settings
  *
  * Value   Win0 Win1 Win2 Win3 Win 4
-- 
1.7.9.5

[Bug 79850] [awesomenauts][radeonsi] pageflip is clearly missing vblank with vsync on

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

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

--- Comment #15 from Sylvain BERTRAND  ---
Don't take it personally, but I don't usually work on MIT/BSD licensed code on
my free time because of ethics. If AMD drops all "closed source" components for
linux, then I think it will be ok.

Nevertheless, I'll see what I can reasonably do. I did shot down some pesky
bugs in the DRM driver because I was refactoring the code for a custom radeon
southern islands driver (I'm sylware, ask Alex. D.).

Moreover, I follow the page flip thread on DRI dev mailing list... things seems
still broken there.

The fedora rawhide SDK is a pain, and my dev systems are clean 64 bits (then no
steam/games debugging).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140624/167f6243/attachment.html>

[Bug 78221] 3.16 RC1: AMD R9 270 GPU locks up on some heavy 2D activity - GPU VM fault occurs. (possibly DMA copying issue strikes back?)

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

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

Alex Deucher  changed:

   What|Removed |Added

 Attachment #140721|0   |1
is obsolete||

--- Comment #11 from Alex Deucher  ---
Created attachment 140881
  --> https://bugzilla.kernel.org/attachment.cgi?id=140881=edit
patch 2/2

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 78221] 3.16 RC1: AMD R9 270 GPU locks up on some heavy 2D activity - GPU VM fault occurs. (possibly DMA copying issue strikes back?)

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

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

Alex Deucher  changed:

   What|Removed |Added

 Attachment #140711|0   |1
is obsolete||

--- Comment #10 from Alex Deucher  ---
Created attachment 140871
  --> https://bugzilla.kernel.org/attachment.cgi?id=140871=edit
patch 1/2

Sorry, updated patches.  These apply against 3.15.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH] drm/exynos: Support DP CLKCON register in FIMD driver

[Andrzej Hajda]

On 06/24/2014 03:14 PM, Ajay kumar wrote:
> On Tue, Jun 24, 2014 at 9:01 AM, Andrzej Hajda  wrote:
>> Hi Ajay,
>>
>> On 06/24/2014 01:09 PM, Ajay Kumar wrote:
>>> Add the missing setting for DP CLKCON register.
>>>
>>> This register is present on Exynos5 based FIMD controllers,
>>> and needs to be used if we are using DP.
>>>
>>> Signed-off-by: Ajay Kumar 
>>> ---
>>>  drivers/gpu/drm/exynos/exynos_drm_fimd.c |5 +
>>>  include/video/samsung_fimd.h |4 
>>>  2 files changed, 9 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
>>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> index 33161ad..5d3045d 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> @@ -72,6 +72,7 @@ struct fimd_driver_data {
>>>   unsigned int has_shadowcon:1;
>>>   unsigned int has_clksel:1;
>>>   unsigned int has_limited_fmt:1;
>>> + unsigned int has_dp_clkcon:1;
>>>  };
>>>
>>>  static struct fimd_driver_data s3c64xx_fimd_driver_data = {
>>> @@ -88,6 +89,7 @@ static struct fimd_driver_data exynos4_fimd_driver_data = 
>>> {
>>>  static struct fimd_driver_data exynos5_fimd_driver_data = {
>>>   .timing_base = 0x2,
>>>   .has_shadowcon = 1,
>>> + .has_dp_clkcon = 1,
>>>  };
>>>
>>>  struct fimd_win_data {
>>> @@ -331,6 +333,9 @@ static void fimd_commit(struct exynos_drm_manager *mgr)
>>>   if (clkdiv > 1)
>>>   val |= VIDCON0_CLKVAL_F(clkdiv - 1) | VIDCON0_CLKDIR;
>>>
>>> + if (ctx->driver_data->has_dp_clkcon)
>>> + writel(DP_CLK_ENABLE, ctx->regs + DP_CLKCON);
>>> +
>> This code always enables the clock on exynos5. As I understand it should
>> be enabled only if DP is used.
> Right!
> But, when I searched for the display interface,
> only exynos4 based boards use MIPI/DPI, and all exynos5 based boards use DP.
> So, I thought adding this in driver_data for exynos5 should be fine.

Arndale and Arndale-Octa have MIPI/DSI interface with MIPI/LVDS bridge.

>
> Inki/Andrej - Shall I add it as an optional DT property?

No, property is redundant. The simplest solution could be to use
CONFIG_DRM_EXYNOS_DP
macro but it is quite ugly.
I guess extending little bit exynos_drm framework to allow detection of
DP in fimd would be better.

Regards
Andrzej

>
> Ajay
>>
>>>   writel(val, ctx->regs + VIDCON0);
>>>  }
>>>
>>> diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
>>> index b039320..d8f4b0b 100644
>>> --- a/include/video/samsung_fimd.h
>>> +++ b/include/video/samsung_fimd.h
>>> @@ -435,6 +435,10 @@
>>>  #define BLENDCON_NEW_8BIT_ALPHA_VALUE(1 << 0)
>>>  #define BLENDCON_NEW_4BIT_ALPHA_VALUE(0 << 0)
>>>
>>> +/* Video clock enable for DP */
>>> +#define DP_CLKCON0x27C
>>> +#define DP_CLK_ENABLE0x2
>>> +
>>>  /* Notes on per-window bpp settings
>>>   *
>>>   * Value Win0 Win1 Win2 Win3 Win 4
>>>

[PATCH v14 04/10] imx-drm: use defines for clock polarity settings

[Russell King - ARM Linux]

On Mon, Jun 16, 2014 at 12:11:18PM +0200, Denis Carikli wrote:
> Signed-off-by: Denis Carikli 

It would be nice to have a little more explanation in the commit messages
for these patches.  If you'd like to send me better commit messages for
these patches, I'll add them to what I already have:

imx-drm: use defines for clock polarity settings

imx-drm: add RGB666 support for parallel display.

It may also be worth describing the RGB666 format in the commit message
for:

v4l2: add new V4L2_PIX_FMT_RGB666 pixel format.

And... getting some more acks for these patches would be very useful,
I think I'd like to see Sascha's ack for these... Sascha?

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

[PATCH v14 08/10] drm/panel: Add Eukrea mbimxsd51 displays.

[Russell King - ARM Linux]

Denis,

This patch creates binding documentation.  Any patch which does so
should be copied to the DT people so they can review the bindings
and give appropriate acks.  It would be better if you separate the
binding documentation updates from the other functional changes too.

I've added them on this reply to see whether they'll feel friendly
enough to comment on the patch as it stands to avoid having to go
through two more rounds on this already-fourteen revision patch set.

On Mon, Jun 16, 2014 at 12:11:22PM +0200, Denis Carikli wrote:
> Signed-off-by: Denis Carikli 
> ---
> ChangeLog v13->v14:
> - None
> 
> ChangeLog v12->v13:
> - Added a note explaining why the size is zero in
>   the eukrea_mbimxsd51_dvi(s)vga structs.
> ChangeLog v11->v12:
> - Rebased: It now uses the new DRM_MODE_FLAG_POL_DE flags defines names
> 
> ChangeLog v10->v11:
> - New patch.
> ---
>  .../bindings/panel/eukrea,mbimxsd51-cmo-qvga.txt   |7 ++
>  .../bindings/panel/eukrea,mbimxsd51-dvi-svga.txt   |7 ++
>  .../bindings/panel/eukrea,mbimxsd51-dvi-vga.txt|7 ++
>  drivers/gpu/drm/panel/panel-simple.c   |   83 
> 
>  4 files changed, 104 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-cmo-qvga.txt
>  create mode 100644 
> Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-svga.txt
>  create mode 100644 
> Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-vga.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-cmo-qvga.txt 
> b/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-cmo-qvga.txt
> new file mode 100644
> index 000..03679d0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-cmo-qvga.txt
> @@ -0,0 +1,7 @@
> +Eukrea CMO-QVGA (320x240 pixels) TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "eukrea,mbimxsd51-cmo-qvga"
> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.
> diff --git 
> a/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-svga.txt 
> b/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-svga.txt
> new file mode 100644
> index 000..f408c9a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-svga.txt
> @@ -0,0 +1,7 @@
> +Eukrea DVI-SVGA (800x600 pixels) DVI output.
> +
> +Required properties:
> +- compatible: should be "eukrea,mbimxsd51-dvi-svga"
> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.
> diff --git 
> a/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-vga.txt 
> b/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-vga.txt
> new file mode 100644
> index 000..8ea90da
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-vga.txt
> @@ -0,0 +1,7 @@
> +Eukrea DVI-VGA (640x480 pixels) DVI output.
> +
> +Required properties:
> +- compatible: should be "eukrea,mbimxsd51-dvi-vga"
> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.
> diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> b/drivers/gpu/drm/panel/panel-simple.c
> index a251361..adc40a7 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -403,6 +403,80 @@ static const struct panel_desc edt_etm0700g0dh6 = {
>   },
>  };
>  
> +static const struct drm_display_mode eukrea_mbimxsd51_cmoqvga_mode = {
> + .clock = 6500,
> + .hdisplay = 320,
> + .hsync_start = 320 + 38,
> + .hsync_end = 320 + 38 + 20,
> + .htotal = 320 + 38 + 20 + 30,
> + .vdisplay = 240,
> + .vsync_start = 240 + 15,
> + .vsync_end = 240 + 15 + 4,
> + .vtotal = 240 + 15 + 4 + 3,
> + .vrefresh = 60,
> + .pol_flags = DRM_MODE_FLAG_POL_PIXDATA_NEGEDGE |
> +  DRM_MODE_FLAG_POL_DE_LOW,
> +};
> +
> +static const struct panel_desc eukrea_mbimxsd51_cmoqvga = {
> + .modes = _mbimxsd51_cmoqvga_mode,
> + .num_modes = 1,
> + .size = {
> + .width = 73,
> + .height = 56,
> + },
> +};
> +
> +static const struct drm_display_mode eukrea_mbimxsd51_dvisvga_mode = {
> + .clock = 44333,
> + .hdisplay = 800,
> + .hsync_start = 800 + 112,
> + .hsync_end = 800 + 112 + 32,
> + .htotal = 800 + 112 + 32 + 80,
> + .vdisplay = 600,
> + .vsync_start = 600 + 3,
> + .vsync_end = 600 + 3 + 17,
> + .vtotal = 600 + 3 + 17 + 4,
> + .vrefresh = 60,
> + .pol_flags = DRM_MODE_FLAG_POL_PIXDATA_POSEDGE |
> +  DRM_MODE_FLAG_POL_DE_HIGH,
> +};
> +
> +static const struct panel_desc eukrea_mbimxsd51_dvisvga = {
> + .modes = _mbimxsd51_dvisvga_mode,
> + .num_modes = 1,
> + /* This is a DVI adapter for external displays */
> + .size = {
> + .width = 0,
> + 

[PATCH v14 05/10] ARM: dts: imx5*, imx6*: correct display-timings nodes.

[Russell King - ARM Linux]

On Mon, Jun 16, 2014 at 12:11:19PM +0200, Denis Carikli wrote:
> The imx-drm driver can't use the de-active and
> pixelclk-active display-timings properties yet.
> 
> Instead the data-enable and the pixel data clock
> polarity are hardcoded in the imx-drm driver.
> 
> So theses properties are now set to keep
> the same behaviour when imx-drm will start
> using them.
> 
> Signed-off-by: Denis Carikli 

This patch needs either an ack from the arm-soc/iMX maintainers, or
they need to merge it.  As there's little positive agreement on the
series, I can understand why there's reluctance to merge it.

So, can we start having some acks from people please, or at least
commitments to merge this patch when the others are deemed to be
acceptable.  If not, can we have explanations why this should not
be merged.

Thanks.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

[Nouveau] [PATCH v2 2/3] drm/ttm: introduce dma cache sync helpers

[Lucas Stach]

Am Dienstag, den 24.06.2014, 22:52 +0900 schrieb Alexandre Courbot:
> On Tue, Jun 24, 2014 at 10:25 PM, Lucas Stach  
> wrote:
> > Am Dienstag, den 24.06.2014, 14:27 +0200 schrieb Maarten Lankhorst:
> >> op 24-06-14 14:23, Alexandre Courbot schreef:
> >> > On Tue, Jun 24, 2014 at 7:55 PM, Alexandre Courbot  >> > nvidia.com> wrote:
> >> >> On 06/24/2014 07:33 PM, Alexandre Courbot wrote:
> >> >>> On 06/24/2014 07:02 PM, Russell King - ARM Linux wrote:
> >>  On Tue, Jun 24, 2014 at 06:54:26PM +0900, Alexandre Courbot wrote:
> >> > From: Lucas Stach 
> >> >
> >> > On architectures for which access to GPU memory is non-coherent,
> >> > caches need to be flushed and invalidated explicitly at the
> >> > appropriate places. Introduce two small helpers to make things
> >> > easy for TTM-based drivers.
> >> 
> >>  Have you run this with DMA API debugging enabled?  I suspect you 
> >>  haven't,
> >>  and I recommend that you do.
> >> >>>
> >> >>> # cat /sys/kernel/debug/dma-api/error_count
> >> >>> 162621
> >> >>>
> >> >>> (??? ???)
> >> >>
> >> >> *puts table back on its feet*
> >> >>
> >> >> So, yeah - TTM memory is not allocated using the DMA API, hence we 
> >> >> cannot
> >> >> use the DMA API to sync it. Thanks Russell for pointing it out.
> >> >>
> >> >> The only alternative I see here is to flush the CPU caches when syncing 
> >> >> for
> >> >> the device, and invalidate them for the other direction. Of course if 
> >> >> the
> >> >> device has caches on its side as well the opposite operation must also 
> >> >> be
> >> >> done for it. Guess the only way is to handle it all by ourselves here. 
> >> >> :/
> >> > ... and it really sucks. Basically if we cannot use the DMA API here
> >> > we will lose the convenience of having a portable API that does just
> >> > the right thing for the underlying platform. Without it we would have
> >> > to duplicate arm_iommu_sync_single_for_cpu/device() and we would only
> >> > have support for ARM.
> >> >
> >> > The usage of the DMA API that we are doing might be illegal, but in
> >> > essence it does exactly what we need - at least for ARM. What are the
> >> > alternatives?
> >> Convert TTM to use the dma api? :-)
> >
> > Actually TTM already has a page alloc backend using the DMA API. It's
> > just not used for the standard case right now.
> 
> Indeed, and Nouveau even already makes use of it if CONFIG_SWIOTLB is
> set apparently.
> 
> > I would argue that we should just use this page allocator (which has the
> > side effect of getting pages from CMA if available -> you are actually
> > free to change the caching) and do away with the other allocator in the
> > ARM case.
> 
> Mm? Does it mean that CMA memory is not mapped into lowmem? That would
> certainly help in the present case, but I wonder how useful it will be
> once the iommu support is in place. Will also need to consider
> performance of such coherent memory for e.g. user-space mappings.
> 
> Anyway, I will experiment a bit with this tomorrow, thanks!

CMA memory is reserved before the lowmem section mapping is set up. It
is then mapped with individual 4k pages before giving it back to the
buddy allocator.
This means CMA pages in use by the kernel are mapped into lowmem, but
they are actually unmapped from lowmem once you allocate them as DMA
memory.

Regards,
Lucas

-- 
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

[PATCH v14 06/10] drm: drm_display_mode: add signal polarity flags

[Russell King - ARM Linux]

On Mon, Jun 16, 2014 at 12:11:20PM +0200, Denis Carikli wrote:
> We need a way to pass signal polarity informations
>   between DRM panels, and the display drivers.
> 
> To do that, a pol_flags field was added to drm_display_mode.
> 
> Signed-off-by: Denis Carikli 

This patch needs an ack from the DRM people - can someone review it
please?  This series has now been round 14 revisions and it's about
time it was properly reviewed - or a statement made if it's
unacceptable.

> ---
> ChangeLog v13->v14:
> - Fixed DRM_MODE_FLAG_POL_DE_HIGH's description.
> ChangeLog v12->v13:
> - Added Docbook documentation for pol_flags the struct field.
> - Removed the _PRESERVE   defines: it was used by patches
>   against the imx_drm driver. Now theses patches have been
>   adapted not to require that defines.
> ChangeLog v11->v12:
> - Rebased: This patch now applies against drm_modes.h
> - Rebased: It now uses the new DRM_MODE_FLAG_POL_DE flags defines names
> 
> ChangeLog v10->v11:
> - Since the imx-drm won't be able to retrive its regulators
>   from the device tree when using display-timings nodes,
>   and that I was told that the drm simple-panel driver 
>   already supported that, I then, instead, added what was
>   lacking to make the eukrea displays work with the
>   drm-simple-panel driver.
> 
>   That required a way to get back the display polarity
>   informations from the imx-drm driver without affecting
>   userspace.
> ---
>  Documentation/DocBook/drm.tmpl |   30 ++
>  include/drm/drm_modes.h|6 ++
>  2 files changed, 36 insertions(+)
> 
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index 7df3134..22d435f 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -2292,6 +2292,36 @@ void intel_crt_init(struct drm_device *dev)
>  and height_mm fields are only used 
> internally
>  during EDID parsing and should not be set when creating modes 
> manually.
>
> +  
> +The pol_flags value represents the 
> display
> +signal polarity flags, it can be a combination of
> +
> +  
> +DRM_MODE_FLAG_POL_PIXDATA_NEGEDGE
> + 
> + drive pixel data on falling edge, sample data on rising 
> edge.
> + 
> +  
> +  
> +DRM_MODE_FLAG_POL_PIXDATA_POSEDGE
> +
> +  Drive pixel data on rising edge, sample data on falling 
> edge.
> +
> +  
> +  
> +DRM_MODE_FLAG_POL_DE_LOW
> +
> +  data-enable pulse is active low
> +
> +  
> +  
> +DRM_MODE_FLAG_POL_DE_HIGH
> +
> +  data-enable pulse is active high
> +
> +  
> +
> +  
>  
>  
>int (*mode_valid)(struct drm_connector *connector,
> diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
> index 91d0582..c5cbe31 100644
> --- a/include/drm/drm_modes.h
> +++ b/include/drm/drm_modes.h
> @@ -93,6 +93,11 @@ enum drm_mode_status {
>  
>  #define DRM_MODE_FLAG_3D_MAX DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF
>  
> +#define DRM_MODE_FLAG_POL_PIXDATA_NEGEDGEBIT(1)
> +#define DRM_MODE_FLAG_POL_PIXDATA_POSEDGEBIT(2)
> +#define DRM_MODE_FLAG_POL_DE_LOW BIT(3)
> +#define DRM_MODE_FLAG_POL_DE_HIGHBIT(4)
> +
>  struct drm_display_mode {
>   /* Header */
>   struct list_head head;
> @@ -144,6 +149,7 @@ struct drm_display_mode {
>   int vrefresh;   /* in Hz */
>   int hsync;  /* in kHz */
>   enum hdmi_picture_aspect picture_aspect_ratio;
> + unsigned int pol_flags;
>  };
>  
>  /* mode specified on the command line */
> -- 
> 1.7.9.5
> 

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

[PATCH 1/3] drm/radeon: stop poisoning the GART TLB

[Michel Dänzer]

On 23.06.2014 18:56, Christian K?nig wrote:
> Am 23.06.2014 10:15, schrieb Michel D?nzer:
>> On 19.06.2014 18:45, Christian K?nig wrote:
>>
>>> I think even when we revert to the old code we have a couple of unsolved
>>> problems with the VM support or in the driver in general where we should
>>> try to understand the underlying reason for it instead of applying more
>>> workarounds.
>> I'm not suggesting applying more workarounds but going back to a known
>> more stable state. It seems like we've maneuvered ourselves to a rather
>> uncomfortable position from there, with no clear way to a better place.
>> But if we basically started from the 3.14 state again, we have a few
>> known hurdles like mine and Marek's Bonaire etc. which we know any
>> further improvements will have to pass before they can be considered for
>> general consumption.
> 
> Yeah agree, especially on the uncomfortable position.
> 
> Please try with the two attached patches applied on top of 3.15 and
> retest. They should revert back to the old implementation.

Unfortunately, X fails to start with these, see the attached excerpt
from dmesg.


-- 
Earthling Michel D?nzer|  http://www.amd.com
Libre software enthusiast  |Mesa and X developer
-- next part --
[5.401968] radeon :01:00.0: bo 8800db841000 va 0x conflict 
with (bo 8800db841000 0x0010 0x0020)
[5.402095] radeon :01:00.0: still active bo inside vm
[5.402132] 
[5.402141] ==
[5.402171] [ INFO: possible circular locking dependency detected ]
[5.402202] 3.15.0 #133 Tainted: G   O 
[5.402225] ---
[5.402251] Xorg/855 is trying to acquire lock:
[5.402272]  (reservation_ww_class_mutex){+.+.+.}, at: [] 
radeon_vm_fini+0xcf/0x1b6 [radeon]
[5.402340] 
[5.402340] but task is already holding lock:
[5.402366]  (>mutex){+.+...}, at: [] 
radeon_vm_fini+0x3a/0x1b6 [radeon]
[5.402424] 
[5.402424] which lock already depends on the new lock.
[5.402424] 
[5.402463] 
[5.402463] the existing dependency chain (in reverse order) is:
[5.402500] 
[5.402500] -> #1 (>mutex){+.+...}:
[5.402528][] lock_acquire+0xa1/0x111
[5.402561][] mutex_lock_nested+0x72/0x3c6
[5.402597][] radeon_vm_bo_add+0x7b/0xbd [radeon]
[5.402638][] radeon_driver_open_kms+0xa0/0x174 
[radeon]
[5.402679][] drm_open+0x230/0x456 [drm]
[5.402717][] drm_stub_open+0xad/0xde [drm]
[5.402755][] chrdev_open+0x143/0x169
[5.402792][] do_dentry_open+0x223/0x238
[5.402824][] finish_open+0x2e/0x38
[5.402854][] do_last+0x846/0xa01
[5.402886][] path_openat+0x235/0x4ef
[5.402917][] do_filp_open+0x35/0x7a
[5.402948][] do_sys_open+0x6b/0xfa
[5.402975][] SyS_open+0x19/0x1b
[5.403004][] system_call_fastpath+0x16/0x1b
[5.403038] 
[5.403038] -> #0 (reservation_ww_class_mutex){+.+.+.}:
[5.403071][] __lock_acquire+0xae5/0xd9c
[5.403103][] lock_acquire+0xa1/0x111
[5.403132][] 
mutex_lock_interruptible_nested+0x72/0x3d5
[5.403168][] radeon_vm_fini+0xcf/0x1b6 [radeon]
[5.403212][] radeon_driver_open_kms+0x133/0x174 
[radeon]
[5.403253][] drm_open+0x230/0x456 [drm]
[5.403289][] drm_stub_open+0xad/0xde [drm]
[5.403325][] chrdev_open+0x143/0x169
[5.403356][] do_dentry_open+0x223/0x238
[5.403389][] finish_open+0x2e/0x38
[5.403417][] do_last+0x846/0xa01
[5.403446][] path_openat+0x235/0x4ef
[5.403478][] do_filp_open+0x35/0x7a
[5.403508][] do_sys_open+0x6b/0xfa
[5.403537][] SyS_open+0x19/0x1b
[5.403567][] system_call_fastpath+0x16/0x1b
[5.403597] 
[5.403597] other info that might help us debug this:
[5.403597] 
[5.403632]  Possible unsafe locking scenario:
[5.403632] 
[5.403660]CPU0CPU1
[5.404874]
[5.406077]   lock(>mutex);
[5.407250]lock(reservation_ww_class_mutex);
[5.408449]lock(>mutex);
[5.409601]   lock(reservation_ww_class_mutex);
[5.410759] 
[5.410759]  *** DEADLOCK ***
[5.410759] 
[5.414095] 2 locks held by Xorg/855:
[5.415180]  #0:  (drm_global_mutex){+.+.+.}, at: [] 
drm_stub_open+0x3d/0xde [drm]
[5.416333]  #1:  (>mutex){+.+...}, at: [] 
radeon_vm_fini+0x3a/0x1b6 [radeon]
[5.417487] 
[5.417487] stack backtrace:
[5.419659] CPU: 2 PID: 855 Comm: Xorg Tainted: G   O  3.15.0 #133
[5.420762] Hardware name: System manufacturer System Product Name/A88X-PRO, 
BIOS 1001 04/01/2014
[

[Nouveau] [PATCH v2 2/3] drm/ttm: introduce dma cache sync helpers

[Lucas Stach]

Am Dienstag, den 24.06.2014, 14:27 +0200 schrieb Maarten Lankhorst:
> op 24-06-14 14:23, Alexandre Courbot schreef:
> > On Tue, Jun 24, 2014 at 7:55 PM, Alexandre Courbot  
> > wrote:
> >> On 06/24/2014 07:33 PM, Alexandre Courbot wrote:
> >>> On 06/24/2014 07:02 PM, Russell King - ARM Linux wrote:
>  On Tue, Jun 24, 2014 at 06:54:26PM +0900, Alexandre Courbot wrote:
> > From: Lucas Stach 
> >
> > On architectures for which access to GPU memory is non-coherent,
> > caches need to be flushed and invalidated explicitly at the
> > appropriate places. Introduce two small helpers to make things
> > easy for TTM-based drivers.
> 
>  Have you run this with DMA API debugging enabled?  I suspect you haven't,
>  and I recommend that you do.
> >>>
> >>> # cat /sys/kernel/debug/dma-api/error_count
> >>> 162621
> >>>
> >>> (??? ???)
> >>
> >> *puts table back on its feet*
> >>
> >> So, yeah - TTM memory is not allocated using the DMA API, hence we cannot
> >> use the DMA API to sync it. Thanks Russell for pointing it out.
> >>
> >> The only alternative I see here is to flush the CPU caches when syncing for
> >> the device, and invalidate them for the other direction. Of course if the
> >> device has caches on its side as well the opposite operation must also be
> >> done for it. Guess the only way is to handle it all by ourselves here. :/
> > ... and it really sucks. Basically if we cannot use the DMA API here
> > we will lose the convenience of having a portable API that does just
> > the right thing for the underlying platform. Without it we would have
> > to duplicate arm_iommu_sync_single_for_cpu/device() and we would only
> > have support for ARM.
> >
> > The usage of the DMA API that we are doing might be illegal, but in
> > essence it does exactly what we need - at least for ARM. What are the
> > alternatives?
> Convert TTM to use the dma api? :-)

Actually TTM already has a page alloc backend using the DMA API. It's
just not used for the standard case right now.

I would argue that we should just use this page allocator (which has the
side effect of getting pages from CMA if available -> you are actually
free to change the caching) and do away with the other allocator in the
ARM case.

Regards,
Lucas
-- 
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

[PATCH] drm/exynos: Support DP CLKCON register in FIMD driver

[Andrzej Hajda]

Hi Ajay,

On 06/24/2014 01:09 PM, Ajay Kumar wrote:
> Add the missing setting for DP CLKCON register.
> 
> This register is present on Exynos5 based FIMD controllers,
> and needs to be used if we are using DP.
> 
> Signed-off-by: Ajay Kumar 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c |5 +
>  include/video/samsung_fimd.h |4 
>  2 files changed, 9 insertions(+)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 33161ad..5d3045d 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -72,6 +72,7 @@ struct fimd_driver_data {
>   unsigned int has_shadowcon:1;
>   unsigned int has_clksel:1;
>   unsigned int has_limited_fmt:1;
> + unsigned int has_dp_clkcon:1;
>  };
>  
>  static struct fimd_driver_data s3c64xx_fimd_driver_data = {
> @@ -88,6 +89,7 @@ static struct fimd_driver_data exynos4_fimd_driver_data = {
>  static struct fimd_driver_data exynos5_fimd_driver_data = {
>   .timing_base = 0x2,
>   .has_shadowcon = 1,
> + .has_dp_clkcon = 1,
>  };
>  
>  struct fimd_win_data {
> @@ -331,6 +333,9 @@ static void fimd_commit(struct exynos_drm_manager *mgr)
>   if (clkdiv > 1)
>   val |= VIDCON0_CLKVAL_F(clkdiv - 1) | VIDCON0_CLKDIR;
>  
> + if (ctx->driver_data->has_dp_clkcon)
> + writel(DP_CLK_ENABLE, ctx->regs + DP_CLKCON);
> +

This code always enables the clock on exynos5. As I understand it should
be enabled only if DP is used.

Regards
Andrzej


>   writel(val, ctx->regs + VIDCON0);
>  }
>  
> diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
> index b039320..d8f4b0b 100644
> --- a/include/video/samsung_fimd.h
> +++ b/include/video/samsung_fimd.h
> @@ -435,6 +435,10 @@
>  #define BLENDCON_NEW_8BIT_ALPHA_VALUE(1 << 0)
>  #define BLENDCON_NEW_4BIT_ALPHA_VALUE(0 << 0)
>  
> +/* Video clock enable for DP */
> +#define DP_CLKCON0x27C
> +#define DP_CLK_ENABLE0x2
> +
>  /* Notes on per-window bpp settings
>   *
>   * Value Win0 Win1 Win2 Win3 Win 4
> 

[Intel-gfx] [PATCH 2/2] drm/i915: rework digital port IRQ handling (v2)

[Todd Previte]

hotplug_trigger, dig_hotplug_reg, hpd_cpt);
>
> if (pch_iir & SDE_AUDIO_POWER_MASK_CPT) {
> int port = ffs((pch_iir & SDE_AUDIO_POWER_MASK_CPT) >>
> @@ -4338,6 +4481,7 @@ void intel_irq_init(struct drm_device *dev)
> struct drm_i915_private *dev_priv = dev->dev_private;
>
> INIT_WORK(_priv->hotplug_work, i915_hotplug_work_func);
> + INIT_WORK(_priv->dig_port_work, i915_digport_work_func);
> INIT_WORK(_priv->gpu_error.work, i915_error_work_func);
> INIT_WORK(_priv->rps.work, gen6_pm_rps_work);
> INIT_WORK(_priv->l3_parity.error_work, ivybridge_parity_work);
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index b17b9c7..a80cb3e 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1705,6 +1705,9 @@ void intel_ddi_init(struct drm_device *dev, enum 
> port port)
> intel_encoder->cloneable = 0;
> intel_encoder->hot_plug = intel_ddi_hot_plug;
>
> + intel_dig_port->hpd_pulse = intel_dp_hpd_pulse;
> + dev_priv->hpd_irq_port[port] = intel_dig_port;
> +
> if (init_dp)
> dp_connector = intel_ddi_init_dp_connector(intel_dig_port);
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> b/drivers/gpu/drm/i915/intel_dp.c
> index d01bb43..f110522 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3699,6 +3699,22 @@ intel_dp_hot_plug(struct intel_encoder 
> *intel_encoder)
> intel_dp_check_link_status(intel_dp);
> }
>
> +bool
> +intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool 
> long_hpd)
> +{
> + struct intel_dp *intel_dp = _dig_port->dp;
> +
> + if (long_hpd)
> + return true;
> +
> + /*
> + * we'll check the link status via the normal hot plug path later -
> + * but for short hpds we should check it now
> + */
> + intel_dp_check_link_status(intel_dp);
> + return false;
> +}
> +
> /* Return which DP Port should be selected for Transcoder DP control */
> int
> intel_trans_dp_port_sel(struct drm_crtc *crtc)
> @@ -4273,6 +4289,7 @@ intel_dp_init_connector(struct 
> intel_digital_port *intel_dig_port,
> void
> intel_dp_init(struct drm_device *dev, int output_reg, enum port port)
> {
> + struct drm_i915_private *dev_priv = dev->dev_private;
> struct intel_digital_port *intel_dig_port;
> struct intel_encoder *intel_encoder;
> struct drm_encoder *encoder;
> @@ -4328,6 +4345,9 @@ intel_dp_init(struct drm_device *dev, int 
> output_reg, enum port port)
> intel_encoder->cloneable = 0;
> intel_encoder->hot_plug = intel_dp_hot_plug;
>
> + intel_dig_port->hpd_pulse = intel_dp_hpd_pulse;
> + dev_priv->hpd_irq_port[port] = intel_dig_port;
> +
> if (!intel_dp_init_connector(intel_dig_port, intel_connector)) {
> drm_encoder_cleanup(encoder);
> kfree(intel_dig_port);
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index f1d5897..9666ec3 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -563,6 +563,7 @@ struct intel_digital_port {
> u32 saved_port_bits;
> struct intel_dp dp;
> struct intel_hdmi hdmi;
> + bool (*hpd_pulse)(struct intel_digital_port *, bool);
> };
>
> static inline int
> @@ -830,6 +831,7 @@ void intel_edp_psr_enable(struct intel_dp *intel_dp);
> void intel_edp_psr_disable(struct intel_dp *intel_dp);
> void intel_edp_psr_update(struct drm_device *dev);
> void intel_dp_set_drrs_state(struct drm_device *dev, int refresh_rate);
> +bool intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, 
> bool long_hpd);
>
> /* intel_dsi.c */
> bool intel_dsi_init(struct drm_device *dev);
> Dave Airlie <mailto:airlied at gmail.com>
> Tuesday, June 17, 2014 6:29 PM
> Can we get these merged or even looked at?, they are blocking the 
> whole MST progress,
> and I don't have any insight to secret Intel review process. :-)
>
> Dave.
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Sent with Postbox <http://www.getpostbox.com>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140624/cb2ac0c0/attachment-0001.html>
-- next part --
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1291 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140624/cb2ac0c0/attachment-0001.jpg>

[PATCH 1/2] drm/i915: Add #defines for short/long pulse on gmch platforms

[Todd Previte]

These look like they're already integrated into -nightly? But for the 
record...

Reviewed-by: Todd Previte 

-T

> Dave Airlie <mailto:airlied at gmail.com>
> Tuesday, June 17, 2014 6:29 PM
> From: Daniel Vetter 
>
> For no reason at all the public docs lack them, and Dave needs them
> for his hpd interrupt rework.
>
> Cc: Dave Airlie 
> Signed-off-by: Daniel Vetter 
> Signed-off-by: Dave Airlie 
> ---
> drivers/gpu/drm/i915/i915_reg.h | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> b/drivers/gpu/drm/i915/i915_reg.h
> index 5122254..5d8ba0c 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -2526,8 +2526,14 @@ enum punit_power_well {
> #define PORTC_HOTPLUG_LIVE_STATUS_VLV (1 << 28)
> #define PORTB_HOTPLUG_LIVE_STATUS_VLV (1 << 29)
> #define PORTD_HOTPLUG_INT_STATUS (3 << 21)
> +#define PORTD_HOTPLUG_INT_LONG_PULSE (2 << 21)
> +#define PORTD_HOTPLUG_INT_SHORT_PULSE (1 << 21)
> #define PORTC_HOTPLUG_INT_STATUS (3 << 19)
> +#define PORTC_HOTPLUG_INT_LONG_PULSE (2 << 19)
> +#define PORTC_HOTPLUG_INT_SHORT_PULSE (1 << 19)
> #define PORTB_HOTPLUG_INT_STATUS (3 << 17)
> +#define PORTB_HOTPLUG_INT_LONG_PULSE (2 << 17)
> +#define PORTB_HOTPLUG_INT_SHORT_PLUSE (1 << 17)
> /* CRT/TV common between gen3+ */
> #define CRT_HOTPLUG_INT_STATUS (1 << 11)
> #define TV_HOTPLUG_INT_STATUS (1 << 10)
> Dave Airlie <mailto:airlied at gmail.com>
> Tuesday, June 17, 2014 6:29 PM
> Can we get these merged or even looked at?, they are blocking the 
> whole MST progress,
> and I don't have any insight to secret Intel review process. :-)
>
> Dave.
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Sent with Postbox <http://www.getpostbox.com>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140624/a913c093/attachment.html>
-- next part --
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1291 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140624/a913c093/attachment.jpg>

[PATCH v14 08/10] drm/panel: Add Eukrea mbimxsd51 displays.

[Rob Herring]

On Tue, Jun 24, 2014 at 10:06 AM, Russell King - ARM Linux
 wrote:
> Denis,
>
> This patch creates binding documentation.  Any patch which does so
> should be copied to the DT people so they can review the bindings
> and give appropriate acks.  It would be better if you separate the
> binding documentation updates from the other functional changes too.
>
> I've added them on this reply to see whether they'll feel friendly
> enough to comment on the patch as it stands to avoid having to go
> through two more rounds on this already-fourteen revision patch set.
>
> On Mon, Jun 16, 2014 at 12:11:22PM +0200, Denis Carikli wrote:
>> Signed-off-by: Denis Carikli 
>> ---
>> ChangeLog v13->v14:
>> - None
>>
>> ChangeLog v12->v13:
>> - Added a note explaining why the size is zero in
>>   the eukrea_mbimxsd51_dvi(s)vga structs.
>> ChangeLog v11->v12:
>> - Rebased: It now uses the new DRM_MODE_FLAG_POL_DE flags defines names
>>
>> ChangeLog v10->v11:
>> - New patch.
>> ---
>>  .../bindings/panel/eukrea,mbimxsd51-cmo-qvga.txt   |7 ++
>>  .../bindings/panel/eukrea,mbimxsd51-dvi-svga.txt   |7 ++
>>  .../bindings/panel/eukrea,mbimxsd51-dvi-vga.txt|7 ++
>>  drivers/gpu/drm/panel/panel-simple.c   |   83 
>> 
>>  4 files changed, 104 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-cmo-qvga.txt
>>  create mode 100644 
>> Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-svga.txt
>>  create mode 100644 
>> Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-vga.txt
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-cmo-qvga.txt 
>> b/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-cmo-qvga.txt
>> new file mode 100644
>> index 000..03679d0
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-cmo-qvga.txt
>> @@ -0,0 +1,7 @@
>> +Eukrea CMO-QVGA (320x240 pixels) TFT LCD panel
>> +
>> +Required properties:
>> +- compatible: should be "eukrea,mbimxsd51-cmo-qvga"
>> +
>> +This binding is compatible with the simple-panel binding, which is specified
>> +in simple-panel.txt in this directory.
>> diff --git 
>> a/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-svga.txt 
>> b/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-svga.txt
>> new file mode 100644
>> index 000..f408c9a
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-svga.txt
>> @@ -0,0 +1,7 @@
>> +Eukrea DVI-SVGA (800x600 pixels) DVI output.
>> +
>> +Required properties:
>> +- compatible: should be "eukrea,mbimxsd51-dvi-svga"
>> +
>> +This binding is compatible with the simple-panel binding, which is specified
>> +in simple-panel.txt in this directory.
>> diff --git 
>> a/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-vga.txt 
>> b/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-vga.txt
>> new file mode 100644
>> index 000..8ea90da
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-vga.txt
>> @@ -0,0 +1,7 @@
>> +Eukrea DVI-VGA (640x480 pixels) DVI output.
>> +
>> +Required properties:
>> +- compatible: should be "eukrea,mbimxsd51-dvi-vga"
>> +
>> +This binding is compatible with the simple-panel binding, which is specified
>> +in simple-panel.txt in this directory.

Seems like we could just have a list of compatible strings rather than
a mostly duplicated file.

>> diff --git a/drivers/gpu/drm/panel/panel-simple.c 
>> b/drivers/gpu/drm/panel/panel-simple.c
>> index a251361..adc40a7 100644
>> --- a/drivers/gpu/drm/panel/panel-simple.c
>> +++ b/drivers/gpu/drm/panel/panel-simple.c
>> @@ -403,6 +403,80 @@ static const struct panel_desc edt_etm0700g0dh6 = {
>>   },
>>  };
>>
>> +static const struct drm_display_mode eukrea_mbimxsd51_cmoqvga_mode = {
>> + .clock = 6500,
>> + .hdisplay = 320,
>> + .hsync_start = 320 + 38,
>> + .hsync_end = 320 + 38 + 20,
>> + .htotal = 320 + 38 + 20 + 30,
>> + .vdisplay = 240,
>> + .vsync_start = 240 + 15,
>> + .vsync_end = 240 + 15 + 4,
>> + .vtotal = 240 + 15 + 4 + 3,
>> + .vrefresh = 60,
>> + .pol_flags = DRM_MODE_FLAG_POL_PIXDATA_NEGEDGE |
>> +  DRM_MODE_FLAG_POL_DE_LOW,

Why aren't you using:

Documentation/devicetree/bindings/video/display-timing.txt

Rob

linux-next: Tree for Jun 19 (drm/i915)

[Jani Nikula]

On Thu, 19 Jun 2014, Randy Dunlap  wrote:
> On 06/18/14 23:16, Stephen Rothwell wrote:
>> Hi all,
>> 
>> The powerpc allyesconfig is again broken more than usual.
>> 
>> Changes since 20140618:
>> 
>
> on i386:
>
> CONFIG_ACPI is not enabled.
>
>   CC  drivers/gpu/drm/i915/i915_drv.o
> ../drivers/gpu/drm/i915/i915_drv.c: In function 'i915_drm_freeze':
> ../drivers/gpu/drm/i915/i915_drv.c:547:2: error: implicit declaration of 
> function 'acpi_target_system_state' [-Werror=implicit-function-declaration]
> ../drivers/gpu/drm/i915/i915_drv.c:547:36: error: 'ACPI_STATE_S3' undeclared 
> (first use in this function)
> ../drivers/gpu/drm/i915/i915_drv.c:547:36: note: each undeclared identifier 
> is reported only once for each function it appears in
>   CC  net/dccp/qpolicy.o
> cc1: some warnings being treated as errors
> make[5]: *** [drivers/gpu/drm/i915/i915_drv.o] Error 1

Thanks for the report, we'll fix it.

Can anyone explain why include/linux/acpi_bus.h has #ifdef
CONFIG_ACPI_SLEEP and conditional build for a dummy inline version of
acpi_target_system_state(), *but* that does not get included or used if
CONFIG_ACPI=n? Additionally, the combination of CONFIG_ACPI=y and
CONFIG_ACPI_SLEEP=n does not seem to work at all.

So we'll really have to sprinkle #ifdef CONFIG_ACPI all over, instead of
neatly using the dummy versions that someone has gone through the
trouble of adding?

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

[Bug 79850] [awesomenauts][radeonsi] pageflip is clearly missing vblank with vsync on

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

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

--- Comment #14 from Michel D?nzer  ---
Can you continue narrowing down why the driver is failing to flip then?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140624/65bc0b44/attachment.html>

[Bug 78661] GPU sometimes locks up after boot and/or resume

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

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

--- Comment #4 from Nikolaus Waxweiler  ---
Will try radeon.dpm=0 and report back.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 78661] GPU sometimes locks up after boot and/or resume

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

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

--- Comment #3 from Nikolaus Waxweiler  ---
Created attachment 140851
  --> https://bugzilla.kernel.org/attachment.cgi?id=140851=edit
Full dmesg output for the day where the hangs occured up to the bug report

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 79850] [awesomenauts][radeonsi] pageflip is clearly missing vblank with vsync on

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

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

--- Comment #13 from Sylvain BERTRAND  ---
Disabled the backing store in xorg.conf for the radeon driver. Checked in
Xorg.0.log it is properly disabled. Tested awesomenauts and life goes on.
Still happening.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140624/b459f033/attachment-0001.html>

[Nouveau] [PATCH v2 2/3] drm/ttm: introduce dma cache sync helpers

[Maarten Lankhorst]

op 24-06-14 14:23, Alexandre Courbot schreef:
> On Tue, Jun 24, 2014 at 7:55 PM, Alexandre Courbot  
> wrote:
>> On 06/24/2014 07:33 PM, Alexandre Courbot wrote:
>>> On 06/24/2014 07:02 PM, Russell King - ARM Linux wrote:
 On Tue, Jun 24, 2014 at 06:54:26PM +0900, Alexandre Courbot wrote:
> From: Lucas Stach 
>
> On architectures for which access to GPU memory is non-coherent,
> caches need to be flushed and invalidated explicitly at the
> appropriate places. Introduce two small helpers to make things
> easy for TTM-based drivers.

 Have you run this with DMA API debugging enabled?  I suspect you haven't,
 and I recommend that you do.
>>>
>>> # cat /sys/kernel/debug/dma-api/error_count
>>> 162621
>>>
>>> (??? ???)
>>
>> *puts table back on its feet*
>>
>> So, yeah - TTM memory is not allocated using the DMA API, hence we cannot
>> use the DMA API to sync it. Thanks Russell for pointing it out.
>>
>> The only alternative I see here is to flush the CPU caches when syncing for
>> the device, and invalidate them for the other direction. Of course if the
>> device has caches on its side as well the opposite operation must also be
>> done for it. Guess the only way is to handle it all by ourselves here. :/
> ... and it really sucks. Basically if we cannot use the DMA API here
> we will lose the convenience of having a portable API that does just
> the right thing for the underlying platform. Without it we would have
> to duplicate arm_iommu_sync_single_for_cpu/device() and we would only
> have support for ARM.
>
> The usage of the DMA API that we are doing might be illegal, but in
> essence it does exactly what we need - at least for ARM. What are the
> alternatives?
Convert TTM to use the dma api? :-)

~Maarten

[PATCH 3/5 v2] drm/exynos: allow mulitple layer updates per vsync for mixer

[Inki Dae]

On 2014? 06? 23? 14:32, Rahul Sharma wrote:
> Allowing only one layer update per vsync can cause issues
> while there are update available for both layers. There is
> a good amount of possibility to loose updates if we allow
> single update per vsync.
> 
> Signed-off-by: Rahul Sharma 
> ---
>  drivers/gpu/drm/exynos/exynos_mixer.c |7 +--
>  1 file changed, 1 insertion(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index d359501..6773b03 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -511,13 +511,8 @@ static void vp_video_buffer(struct mixer_context *ctx, 
> int win)
>  static void mixer_layer_update(struct mixer_context *ctx)
>  {
>   struct mixer_resources *res = >mixer_res;
> - u32 val;
> -
> - val = mixer_reg_read(res, MXR_CFG);
>  
> - /* allow one update per vsync only */
> - if (!(val & MXR_CFG_LAYER_UPDATE_COUNT_MASK))
> - mixer_reg_writemask(res, MXR_CFG, ~0, MXR_CFG_LAYER_UPDATE);
> + mixer_reg_writemask(res, MXR_CFG, ~0, MXR_CFG_LAYER_UPDATE);

Rahul, it looks good to me and ok as is. But above codes don't consider
Exynos4 series. In case of Exynos4xxx SoC,
MXR_CFG_LAYER_UPDATE_COUNT_MASK and MXR_CFG_LAYER_UPDATE of MIXER_CFG
register are reserved fields. So can you work that patch to be
considered for Exynos4xxx SoC? That patch would be additional one.

Anyway, will apply it as is, and I will wait for the additional patch.

Thanks,
Inki Dae

>  }
>  
>  static void mixer_graph_buffer(struct mixer_context *ctx, int win)
> 

[PATCH v2 2/3] drm/ttm: introduce dma cache sync helpers

[Russell King - ARM Linux]

On Tue, Jun 24, 2014 at 09:23:05PM +0900, Alexandre Courbot wrote:
> On Tue, Jun 24, 2014 at 7:55 PM, Alexandre Courbot  
> wrote:
> > The only alternative I see here is to flush the CPU caches when syncing for
> > the device, and invalidate them for the other direction. Of course if the
> > device has caches on its side as well the opposite operation must also be
> > done for it. Guess the only way is to handle it all by ourselves here. :/
> 
> ... and it really sucks. Basically if we cannot use the DMA API here
> we will lose the convenience of having a portable API that does just
> the right thing for the underlying platform. Without it we would have
> to duplicate arm_iommu_sync_single_for_cpu/device() and we would only
> have support for ARM.
> 
> The usage of the DMA API that we are doing might be illegal, but in
> essence it does exactly what we need - at least for ARM. What are the
> alternatives?

It may seem /to you/ as a driver developer to be the easiest thing in
the world to abuse an API in a way that it's not supposed to be used,
and it is easy to do that.

However, what you're actually saying is that you don't respect your
fellow kernel developers who have to maintain the other side of that
interface.  When they need to change the implementation of that
interface, what if those changes then screw your abuse of that
interface.

The reason we define the behaviours and properties of APIs is to give
both the user and the implementer of the API some degree of latitude
in how that interface works, so that it can be maintained into the
future.  If abuses (such as these) are allowed, then we've lost,
because the interface can no longer be sanely maintained - especially
if driver authors eventually end up not caring about their pile of
abuse they've created after they've moved on to new wonderful hardware.

With an API such as the DMA API, where we have hundreds, if not a
thousand users of it, this /really/ matters.

We've been here before with the DMA API on older ARM platforms, where
we've had people abusing the API or going beneath the API because "it
does what they need it to", which then makes stuff much harder to change
at architecture level.

Last time it happened, it was when ARMv6 came along and ARM moved away
from VIVT caches.  The options were either to break the crap drivers
and support ARMv6+ CPUs, or keep the crap drivers working and not
support DMA in any shape or form on ARMv6+.

Obviously, this was too important to for one or two abusive drivers to
block, so I changed the architecture level /anyway/ and just said screw
the drivers which end up being broken by their short-sightedness, they
can either rot or someone else can fix them.

I have no beef for intentionally breaking stuff when people abuse well
defined interfaces and/or refuse to discuss their requirements when
interfaces don't quite do what they want - or worse, refuse to listen
to objections.

As I say, it's disrespectful to your fellow kernel developers to abuse
well defined interfaces.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

[PATCH 3/5 v2] drm/exynos: allow mulitple layer updates per vsync for mixer

[Andreas Färber]

Am 24.06.2014 07:21, schrieb Inki Dae:
> On 2014? 06? 23? 14:32, Rahul Sharma wrote:
>> Allowing only one layer update per vsync can cause issues
>> while there are update available for both layers. There is
>> a good amount of possibility to loose updates if we allow
>> single update per vsync.
>>
>> Signed-off-by: Rahul Sharma 
>> ---
>>  drivers/gpu/drm/exynos/exynos_mixer.c |7 +--
>>  1 file changed, 1 insertion(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
>> b/drivers/gpu/drm/exynos/exynos_mixer.c
>> index d359501..6773b03 100644
>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>> @@ -511,13 +511,8 @@ static void vp_video_buffer(struct mixer_context *ctx, 
>> int win)
>>  static void mixer_layer_update(struct mixer_context *ctx)
>>  {
>>  struct mixer_resources *res = >mixer_res;
>> -u32 val;
>> -
>> -val = mixer_reg_read(res, MXR_CFG);
>>  
>> -/* allow one update per vsync only */
>> -if (!(val & MXR_CFG_LAYER_UPDATE_COUNT_MASK))
>> -mixer_reg_writemask(res, MXR_CFG, ~0, MXR_CFG_LAYER_UPDATE);
>> +mixer_reg_writemask(res, MXR_CFG, ~0, MXR_CFG_LAYER_UPDATE);
> 
> Rahul, it looks good to me and ok as is. But above codes don't consider
> Exynos4 series. In case of Exynos4xxx SoC,
> MXR_CFG_LAYER_UPDATE_COUNT_MASK and MXR_CFG_LAYER_UPDATE of MIXER_CFG
> register are reserved fields. So can you work that patch to be
> considered for Exynos4xxx SoC? That patch would be additional one.
> 
> Anyway, will apply it as is, and I will wait for the additional patch.

If it's not too late, could you fix up "multiple" in the subject? :)

Cheers,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg

[PATCH 00/22] Add and use pci_zalloc_consistent

[Johannes Berg]

On Tue, 2014-06-24 at 09:27 +1000, Julian Calaby wrote:

> > - x = (T)pci_alloc_consistent(E1,E2,E3);
> > + x = pci_zalloc_consistent(E1,E2,E3);
> >   if ((x==NULL) || ...) S
> > - memset((T2)x,0,E2);
> 
> I don't know much about SmPL, but wouldn't having that if statement
> there reduce your matches?

Code that matched without the if statement would be buggy, since it
wouldn't be checking the pci_zalloc_consistent return value properly.l

johannes

[Bug 80419] XCOM: Enemy Unknown Causes lockup

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

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

--- Comment #9 from Laurent carlier  ---
(In reply to comment #8)
> I have been playing xcom:enemy within for a few hours on an up-to-date
> x86_64 fedora rawhide.
> No lock-up yet, but slow like hell. Tahiti XT.

I can reproduce the lockup with mesa 10.2.1 with llvm-3.4.2, mesa-git with
llvm-3.5svn and a radeon PITCAIRN/kernel 3.15.1/kernel 3.16rc1 (Archlinux
x86_64)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140624/69b0e967/attachment.html>

[Bug 80419] XCOM: Enemy Unknown Causes lockup

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

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

--- Comment #8 from Sylvain BERTRAND  ---
I have been playing xcom:enemy within for a few hours on an up-to-date x86_64
fedora rawhide.
No lock-up yet, but slow like hell. Tahiti XT.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140624/454bcacc/attachment.html>

[PATCH 1/3] drm/radeon: stop poisoning the GART TLB

[Christian König]

Am 24.06.2014 08:49, schrieb Michel D?nzer:
> On 23.06.2014 18:56, Christian K?nig wrote:
>> Am 23.06.2014 10:15, schrieb Michel D?nzer:
>>> On 19.06.2014 18:45, Christian K?nig wrote:
>>>
>>>> I think even when we revert to the old code we have a couple of unsolved
>>>> problems with the VM support or in the driver in general where we should
>>>> try to understand the underlying reason for it instead of applying more
>>>> workarounds.
>>> I'm not suggesting applying more workarounds but going back to a known
>>> more stable state. It seems like we've maneuvered ourselves to a rather
>>> uncomfortable position from there, with no clear way to a better place.
>>> But if we basically started from the 3.14 state again, we have a few
>>> known hurdles like mine and Marek's Bonaire etc. which we know any
>>> further improvements will have to pass before they can be considered for
>>> general consumption.
>> Yeah agree, especially on the uncomfortable position.
>>
>> Please try with the two attached patches applied on top of 3.15 and
>> retest. They should revert back to the old implementation.
> Unfortunately, X fails to start with these, see the attached excerpt
> from dmesg.

My fault, incorrectly solved a merge conflict and then failed to test 
the right kernel.

BTW: Wasn't there an option to tell grup to use the latest installed 
kernel instead of the one with the highest version number? Can't seem to 
find that any more.

Please try attached patches instead,
Christian.
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-Revert-drop-non-blocking-allocations-from.patch
Type: text/x-diff
Size: 3415 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140624/d547ba7b/attachment-0002.patch>
-- next part --
A non-text attachment was scrubbed...
Name: 0002-drm-radeon-Revert-use-normal-BOs-for-the-page-tables.patch
Type: text/x-diff
Size: 28063 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140624/d547ba7b/attachment-0003.patch>

unparseable, undocumented /sys/class/drm/.../pstate

[Greg KH]

On Tue, Jun 24, 2014 at 10:06:06AM +1000, Ben Skeggs wrote:
> 
> But, as I said on IRC yesterday, let's just move this to debugfs to
> save this waste of time argument, and move on.

I like that idea, great plan :)

greg k-h

[Bug 78221] 3.16 RC1: AMD R9 270 GPU locks up on some heavy 2D activity - GPU VM fault occurs. (possibly DMA copying issue strikes back?)

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

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

--- Comment #9 from t3st3r at mail.ru ---
Hmm, this patch does not applies cleanly to 3.16-rc1 or -rc2, mostly having
bunch of conflicts in radeon_vm.c, which are a bit over my head to resolve at
this point. Which version of kernel I'm supposed to try?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH v2 2/3] drm/ttm: introduce dma cache sync helpers

[Russell King - ARM Linux]

On Tue, Jun 24, 2014 at 06:54:26PM +0900, Alexandre Courbot wrote:
> From: Lucas Stach 
> 
> On architectures for which access to GPU memory is non-coherent,
> caches need to be flushed and invalidated explicitly at the
> appropriate places. Introduce two small helpers to make things
> easy for TTM-based drivers.

Have you run this with DMA API debugging enabled?  I suspect you haven't,
and I recommend that you do.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

[Intel-gfx] [RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of check class type

[Zhenyu Wang]

On 2014.06.19 17:53:51 +0800, Tiejun Chen wrote:
> Originally the reason to probe ISA bridge instead of Dev31:Fun0
> is to make graphics device passthrough work easy for VMM, that
> only need to expose ISA bridge to let driver know the real
> hardware underneath. This is a requirement from virtualization
> team. Especially in that virtualized environments, XEN, there
> is irrelevant ISA bridge in the system with that legacy qemu
> version specific to xen, qemu-xen-traditional. So to work
> reliably, we should scan through all the ISA bridge devices
> and check for the first match, instead of only checking the
> first one.
> 
> But actually, qemu-xen-traditional, is always enumerated with
> Dev31:Fun0, 00:1f.0 as follows:
> 
> hw/pt-graphics.c:
> 
> intel_pch_init()
> |
> + pci_isa_bridge_init(bus, PCI_DEVFN(0x1f, 0), ...);
> 
> so this mean that isa bridge is still represented with Dev31:Func0
> like the native OS. Furthermore, currently we're pushing VGA
> passthrough support into qemu upstream, and with some discussion,
> we wouldn't set the bridge class type and just expose this devfn.
> 
> So we just go back to check devfn to make life normal.
> 
> Signed-off-by: Tiejun Chen 

This was added historically when supporting graphics device passthrough.
Looks qemu upstream can't accept multiple ISA bridge and our PCH is always
on device 31: func0 as far as I know. Looks good to me.

Reviewed-by: Zhenyu Wang  

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140624/1aad82ab/attachment.sig>

unparseable, undocumented /sys/class/drm/.../pstate

[Ben Skeggs]

On Tue, Jun 24, 2014 at 6:26 AM, Greg KH  wrote:
> On Mon, Jun 23, 2014 at 04:18:39PM -0400, Ilia Mirkin wrote:
>> On Mon, Jun 23, 2014 at 4:15 PM, Pavel Machek  wrote:
>> > Hi!
>> >
>> >> >> >> > I guess better interface would be something like
>> >> >> >> >
>> >> >> >> > pstate/07/core_clock_min
>> >> >> >> >   core_clock_max
>> >> >> >> >   memory_clock_min
>> >> >> >> >   memory_clock_max
>> >> >> >> >
>> >> >> >> > and then pstate/active containing just the number of active state?
>> >> >
>> >> >> Could we just say that the format of this file is one-per-line of
>> >> >>
>> >> >> level: information-for-the-user
>> >> >
>> >> > But it is not.
>> >>
>> >> But it is...
>> >>
>> >> > Management tools will want to parse it, sooner or
>> >> > later.  What is wrong with solution described above?
>> >>
>> >> It is complex and annoying to the people that will actually use it.
>> >
>> > grep -r . pstate/ is actually not that bad...
>>
>> While that's a clever trick that anyone who's done a bunch of stuff
>> with sysfs knows, I doubt the average linux user could come up with
>> that on their own. I know I didn't.
>
> That's fine, why would an "average" Linux user ever need to poke around
> in sysfs?  Again, please describe what you are wanting to have exported
> to userspace, and what userspace is supposed to do with that
> information, before worrying about the actual sysfs file layout.
Because, at the moment, we can't by default give any kind of automatic
clock management policy due to the fact that in a great number of
cases, we'll likely hang the GPU when changing clock speeds.  The
VBIOS defaults aren't sufficient for more demanding games etc, and
people might want to try/risk selecting the highest level anyway to
see if it'll work for them.  When things actually work, this will all
automagically happen based on load and users should never need to
touch it.

So, we want a file users can write the level identifier into.  Which,
shockingly, is exactly what the file currently does.

I, however, also decided that people might actually want to know what
this "0x0a" they're echoing into the file actually means; So, in the
output (which is a list of valid identifiers), after the identifier
there's a bunch of " " pairs giving an overview of that
this mysterious "0x0a" is.

Sure, we can remove the information and have the informationless list
of identifiers and we'd suddenly be strictly obeying the rules, then
we've also made any potential userspace tool that we're worried about
a lot more useless (what's it going to do, a drop-down list of 0x07,
0x0a, 0x0e, 0x0f?).

Sure, we can split this all up into a directory structure; and make it
a lot more cumbersome for the intended target of the user who just
wants to override an unfortunate but currently necessary default.  I'm
not sure how exactly one-per-line ":  - ..." is
hard for userspace to deal with (scanf anyone?), but a directory
structure won't be any easier, the available files will still differ
with each card generation etc and userspace will just have to loop
over a directory list instead of each line of a single file.

But, as I said on IRC yesterday, let's just move this to debugfs to
save this waste of time argument, and move on.

Ben.


>
> greg k-h
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 00/22] Add and use pci_zalloc_consistent

[Julian Calaby]

Hi Joe,

On Tue, Jun 24, 2014 at 5:13 AM, Joe Perches  wrote:
> On Mon, 2014-06-23 at 10:25 -0700, Luis R. Rodriguez wrote:
>> On Mon, Jun 23, 2014 at 06:41:28AM -0700, Joe Perches wrote:
>> > Adding the helper reduces object code size as well as overall
>> > source size line count.
>> >
>> > It's also consistent with all the various zalloc mechanisms
>> > in the kernel.
>> >
>> > Done with a simple cocci script and some typing.
>>
>> Awesome, any chance you can paste in the SmPL? Also any chance
>> we can get this added to a make coccicheck so that maintainers
>> moving forward can use that to ensure that no new code is
>> added that uses the old school API?
>
> Not many of these are recent.
>
> Arnd Bergmann reasonably suggested that the pci_alloc_consistent
> api be converted the the more widely used dma_alloc_coherent.
>
> https://lkml.org/lkml/2014/6/23/513
>
>> Shouldn't these drivers just use the normal dma-mapping API now?
>
> and I replied:
>
> https://lkml.org/lkml/2014/6/23/525
>
>> Maybe.  I wouldn't mind.
>> They do seem to have a trivial bit of unnecessary overhead for
>> hwdev == NULL ? NULL : >dev
>
> Anyway, here's the little script.
> I'm not sure it's worthwhile to add it though.
>
> $ cat ./scripts/coccinelle/api/alloc/pci_zalloc_consistent.cocci
> ///
> /// Use pci_zalloc_consistent rather than
> /// pci_alloc_consistent followed by memset with 0
> ///
> /// This considers some simple cases that are common and easy to validate
> /// Note in particular that there are no ...s in the rule, so all of the
> /// matched code has to be contiguous
> ///
> /// Blatantly cribbed from: scripts/coccinelle/api/alloc/kzalloc-simple.cocci
>
> @@
> type T, T2;
> expression x;
> expression E1,E2,E3;
> statement S;
> @@
>
> - x = (T)pci_alloc_consistent(E1,E2,E3);
> + x = pci_zalloc_consistent(E1,E2,E3);
>   if ((x==NULL) || ...) S
> - memset((T2)x,0,E2);

I don't know much about SmPL, but wouldn't having that if statement
there reduce your matches?

Thanks,

-- 
Julian Calaby

Email: julian.calaby at gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/

[PATCH] drm/exynos: Support DP CLKCON register in FIMD driver

[Ajay kumar]

On Tue, Jun 24, 2014 at 9:01 AM, Andrzej Hajda  wrote:
> Hi Ajay,
>
> On 06/24/2014 01:09 PM, Ajay Kumar wrote:
>> Add the missing setting for DP CLKCON register.
>>
>> This register is present on Exynos5 based FIMD controllers,
>> and needs to be used if we are using DP.
>>
>> Signed-off-by: Ajay Kumar 
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_fimd.c |5 +
>>  include/video/samsung_fimd.h |4 
>>  2 files changed, 9 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> index 33161ad..5d3045d 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> @@ -72,6 +72,7 @@ struct fimd_driver_data {
>>   unsigned int has_shadowcon:1;
>>   unsigned int has_clksel:1;
>>   unsigned int has_limited_fmt:1;
>> + unsigned int has_dp_clkcon:1;
>>  };
>>
>>  static struct fimd_driver_data s3c64xx_fimd_driver_data = {
>> @@ -88,6 +89,7 @@ static struct fimd_driver_data exynos4_fimd_driver_data = {
>>  static struct fimd_driver_data exynos5_fimd_driver_data = {
>>   .timing_base = 0x2,
>>   .has_shadowcon = 1,
>> + .has_dp_clkcon = 1,
>>  };
>>
>>  struct fimd_win_data {
>> @@ -331,6 +333,9 @@ static void fimd_commit(struct exynos_drm_manager *mgr)
>>   if (clkdiv > 1)
>>   val |= VIDCON0_CLKVAL_F(clkdiv - 1) | VIDCON0_CLKDIR;
>>
>> + if (ctx->driver_data->has_dp_clkcon)
>> + writel(DP_CLK_ENABLE, ctx->regs + DP_CLKCON);
>> +
>
> This code always enables the clock on exynos5. As I understand it should
> be enabled only if DP is used.
Right!
But, when I searched for the display interface,
only exynos4 based boards use MIPI/DPI, and all exynos5 based boards use DP.
So, I thought adding this in driver_data for exynos5 should be fine.

Inki/Andrej - Shall I add it as an optional DT property?

Ajay
>
>
>>   writel(val, ctx->regs + VIDCON0);
>>  }
>>
>> diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
>> index b039320..d8f4b0b 100644
>> --- a/include/video/samsung_fimd.h
>> +++ b/include/video/samsung_fimd.h
>> @@ -435,6 +435,10 @@
>>  #define BLENDCON_NEW_8BIT_ALPHA_VALUE(1 << 0)
>>  #define BLENDCON_NEW_4BIT_ALPHA_VALUE(0 << 0)
>>
>> +/* Video clock enable for DP */
>> +#define DP_CLKCON0x27C
>> +#define DP_CLK_ENABLE0x2
>> +
>>  /* Notes on per-window bpp settings
>>   *
>>   * Value Win0 Win1 Win2 Win3 Win 4
>>
>

[PATCH V4 00/10] drm: exynos: few patches to enhance bridge chip support

[Rahul Sharma]

Hi Tomasz,

On 23 June 2014 20:08, Tomasz Figa  wrote:
> Hi Rahul,
>
> On 23.06.2014 15:58, Rahul Sharma wrote:
>> Hi Ajay, Inki,
>>
>> I tested this series for Exynos5420 based peach-pit board,
>> Exynos5800 based Peach-pi board and Exynos5250 based
>> Snow board. I verified with the chrome test environment and
>> able to see upto Login Screen. DPMS on/off functionality and
>> S2R is also working fine for Display. therefore:
>
> What tree did you apply this patches onto? I don't see S2R support for
> Exynos5420 or 5800 in current linux-next (e.g. there are no PMU tables
> present for these SoCs).

I verified them with inflight patches and some private patches. All of them
are available at
https://github.com/exynos-reference/kernel/tree/linux-3.16-rc1-ui-s2r

Regards,
Rahul Sharma.

>
> Best regards,
> Tomasz
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 79850] [awesomenauts][radeonsi] pageflip is clearly missing vblank with vsync on

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

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

--- Comment #12 from Michel D?nzer  ---
I noticed artifacts as you're describing in armagetronad. It's actually
DRI2CanFlip() which failed, because the window pixmap is not the screen pixmap.
This turned out to be because SDL 1.2 enables backing store when supported:
https://bugzilla.libsdl.org/show_bug.cgi?id=2602

Even if awesomenauts doesn't use SDL 1.2, it might be worth disabling backing
store via

 Option "BackingStore" "off"

in xorg.conf or the -bs Xorg command line switch.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140624/cf5fb343/attachment.html>

[Bug 80419] XCOM: Enemy Unknown Causes lockup

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

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

--- Comment #7 from Michel D?nzer  ---
Any chance you could try an LLVM 3.5 snapshot?

Also, if you could log in via ssh and grab dmesg after the problem occurs, that
might be interesting.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140624/36dd5f81/attachment.html>

[Bug 80141] Fails to page flip multiple time, queue overflows waiting for one to finish that never does crashing entire system.

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

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

--- Comment #8 from Michel D?nzer  ---
(In reply to comment #7)
> With 3.15 or newer, might be worth trying the patches from
> http://lists.freedesktop.org/archives/dri-devel/2014-June/062245.html .

Don't bother trying those patches just yet, they don't seem to be working yet.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140624/69d069a8/attachment.html>

[Bug 80419] XCOM: Enemy Unknown Causes lockup

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

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

--- Comment #6 from theamazingjanet at googlemail.com ---
Tried it with Oibaf PPA, llvm 3.4.2 and Mesa git and the issue is still there.
Seemd to lock up even quicker this time.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140624/6bf0a73d/attachment.html>

[Bug 80419] XCOM: Enemy Unknown Causes lockup

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

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

--- Comment #5 from theamazingjanet at googlemail.com ---
> Which version of LLVM? Might be worth trying Mesa 10.2 or even current Git
> master if possible.

I'm using llvm 3.4 (default Ubuntu). Will try Mesa 10.2 as soon as possible.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140624/8fe3bf55/attachment-0001.html>

[Bug 80419] XCOM: Enemy Unknown Causes lockup

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

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

--- Comment #4 from theamazingjanet at googlemail.com ---
Created attachment 101633
  --> https://bugs.freedesktop.org/attachment.cgi?id=101633=edit
glxinfo

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140624/668aa0e2/attachment.html>

[Bug 80419] XCOM: Enemy Unknown Causes lockup

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

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

--- Comment #3 from theamazingjanet at googlemail.com ---
Created attachment 101632
  --> https://bugs.freedesktop.org/attachment.cgi?id=101632=edit
Dmesg

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140624/89e72de3/attachment.html>

[PATCH V4 04/10] drm/panel: Add driver for lvds/edp based panels

[Ajay kumar]

Hi Gmeiner,

On Mon, Jun 23, 2014 at 12:55 PM, Christian Gmeiner
 wrote:
> Hi
>
>
> 2014-06-11 20:27 GMT+02:00 Ajay Kumar :
>> This patch adds a simple driver to handle all the LCD and LED
>> powerup/down routines needed to support eDP/LVDS panels.
>>
>> The LCD and LED units are usually powered up via regulators,
>> and almost on all boards, we will have a BACKLIGHT_EN pin to
>> enable/ disable the backlight.
>> Sometimes, we can have LCD_EN switches as well.
>>
>> The routines in this driver can be used to control
>> panel power sequence on such boards.
>>
>> Signed-off-by: Ajay Kumar 
>> Signed-off-by: Rahul Sharma 
>> ---
>>  .../devicetree/bindings/panel/panel-lvds.txt   |   50 
>>  drivers/gpu/drm/panel/Kconfig  |   10 +
>>  drivers/gpu/drm/panel/Makefile |1 +
>>  drivers/gpu/drm/panel/panel-lvds.c |  262 
>> 
>>  4 files changed, 323 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/panel/panel-lvds.txt
>>  create mode 100644 drivers/gpu/drm/panel/panel-lvds.c
>>
>> diff --git a/Documentation/devicetree/bindings/panel/panel-lvds.txt 
>> b/Documentation/devicetree/bindings/panel/panel-lvds.txt
>> new file mode 100644
>> index 000..7cb6084
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/panel/panel-lvds.txt
>> @@ -0,0 +1,50 @@
>> +panel interface for eDP/lvds panels
>> +
>> +Required properties:
>> +  - compatible: "panel-lvds"
>> +
>> +Optional properties:
>> +   -lcd-en-gpio:
>> +   panel LCD poweron GPIO.
>> +   Indicates which GPIO needs to be powered up as output
>> +   to powerup/enable the switch to the LCD panel.
>> +   -led-en-gpio:
>> +   panel LED enable GPIO.
>> +   Indicates which GPIO needs to be powered up as output
>> +   to enable the backlight.
>> +   -panel-prepare-delay:
>> +   delay value in ms required for panel_prepare process
>> +   Delay in ms needed for the panel LCD unit to
>> +   powerup completely.
>> +   ex: delay needed till eDP panel throws HPD.
>> +   delay needed so that we cans tart reading edid.
>> +   -panel-enable-delay:
>> +   delay value in ms required for panel_enable process
>> +   Delay in ms needed for the panel backlight/LED unit
>> +   to powerup, and delay needed between video_enable and
>> +   backlight_enable.
>> +   -panel-disable-delay:
>> +   delay value in ms required for panel_disable process
>> +   Delay in ms needed for the panel backlight/LED unit
>> +   powerdown, and delay needed between backlight_disable
>> +   and video_disable.
>> +   -panel-unprepare-delay:
>> +   delay value in ms required for panel_post_disable process
>> +   Delay in ms needed for the panel LCD unit to
>> +   to powerdown completely, and the minimum delay needed
>> +   before powering it on again.
>> +   -panel-width-mm: physical panel width [mm]
>> +   -panel-height-mm: physical panel height [mm]
>> +
>
> For what are these two properties are needed?
Actually, these are needed to caluculate DPI(dots/pixels per inch).
That information will be used by the corresponding userspace to
deliver proper size fonts.
You can refer other panel drivers, even they too are using it!

Regards,
Ajay

> If I find some time I will give this patch a try as I need something
> like this for an imx6d based device.
That would be great, Thanks.

Ajay

[PATCH V4 04/10] drm/panel: Add driver for lvds/edp based panels

[Ajay kumar]

Hi Javier,

Thanks for the review.

On Mon, Jun 23, 2014 at 11:30 AM, Javier Martinez Canillas
 wrote:
> Hello Ajay,
>
> Not an extensive review since I'm not familiar with the graphics stack
> but a few things I noticed are commented below.
>
> On Wed, Jun 11, 2014 at 8:27 PM, Ajay Kumar  
> wrote:
>> This patch adds a simple driver to handle all the LCD and LED
>> powerup/down routines needed to support eDP/LVDS panels.
>>
>> The LCD and LED units are usually powered up via regulators,
>> and almost on all boards, we will have a BACKLIGHT_EN pin to
>> enable/ disable the backlight.
>> Sometimes, we can have LCD_EN switches as well.
>>
>> The routines in this driver can be used to control
>> panel power sequence on such boards.
>>
>> Signed-off-by: Ajay Kumar 
>> Signed-off-by: Rahul Sharma 
>> ---
>>  .../devicetree/bindings/panel/panel-lvds.txt   |   50 
>>  drivers/gpu/drm/panel/Kconfig  |   10 +
>>  drivers/gpu/drm/panel/Makefile |1 +
>>  drivers/gpu/drm/panel/panel-lvds.c |  262 
>> 
>>  4 files changed, 323 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/panel/panel-lvds.txt
>>  create mode 100644 drivers/gpu/drm/panel/panel-lvds.c
>>
>> diff --git a/Documentation/devicetree/bindings/panel/panel-lvds.txt 
>> b/Documentation/devicetree/bindings/panel/panel-lvds.txt
>> new file mode 100644
>> index 000..7cb6084
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/panel/panel-lvds.txt
>> @@ -0,0 +1,50 @@
>> +panel interface for eDP/lvds panels
>> +
>> +Required properties:
>> +  - compatible: "panel-lvds"
>> +
>> +Optional properties:
>> +   -lcd-en-gpio:
>> +   panel LCD poweron GPIO.
>> +   Indicates which GPIO needs to be powered up as output
>> +   to powerup/enable the switch to the LCD panel.
>> +   -led-en-gpio:
>> +   panel LED enable GPIO.
>> +   Indicates which GPIO needs to be powered up as output
>> +   to enable the backlight.
>> +   -panel-prepare-delay:
>> +   delay value in ms required for panel_prepare process
>> +   Delay in ms needed for the panel LCD unit to
>> +   powerup completely.
>> +   ex: delay needed till eDP panel throws HPD.
>> +   delay needed so that we cans tart reading edid.
>> +   -panel-enable-delay:
>> +   delay value in ms required for panel_enable process
>> +   Delay in ms needed for the panel backlight/LED unit
>> +   to powerup, and delay needed between video_enable and
>> +   backlight_enable.
>> +   -panel-disable-delay:
>> +   delay value in ms required for panel_disable process
>> +   Delay in ms needed for the panel backlight/LED unit
>> +   powerdown, and delay needed between backlight_disable
>> +   and video_disable.
>> +   -panel-unprepare-delay:
>> +   delay value in ms required for panel_post_disable process
>> +   Delay in ms needed for the panel LCD unit to
>> +   to powerdown completely, and the minimum delay needed
>> +   before powering it on again.
>> +   -panel-width-mm: physical panel width [mm]
>> +   -panel-height-mm: physical panel height [mm]
>> +
>> +Example:
>> +
>> +   panel-lvds {
>> +   compatible = "panel-lvds";
>> +   led-en-gpio = < 0 1>;
>> +   panel-prepare-delay = <40>;
>> +   panel-enable-delay = <20>;
>> +   panel-disable-delay = <20>;
>> +   panel-unprepare-delay = <30>;
>> +   panel-width-mm = <256>;
>> +   panel-height-mm = <144>;
>> +   };
>
> Recently it's considered a good practice to have the DT binding
> documentation in a separate patch.
Ok, will remember this.

>> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
>> index 4ec874d..8fe7ee5 100644
>> --- a/drivers/gpu/drm/panel/Kconfig
>> +++ b/drivers/gpu/drm/panel/Kconfig
>> @@ -30,4 +30,14 @@ config DRM_PANEL_S6E8AA0
>> select DRM_MIPI_DSI
>> select VIDEOMODE_HELPERS
>>
>> +config DRM_PANEL_EDP_LVDS
>> +   tristate "support for eDP/LVDS panels"
>> +   depends on OF && DRM_PANEL
>> +   select VIDEOMODE_HELPERS
>> +   help
>> + DRM panel driver for direct eDP panels or LVDS connected
>> + via DP bridges, that need at most a regulator for LCD unit,
>> + a regulator for LED unit and/or enable GPIOs for LCD or LED units.
>> + Delay values can also be specified to support powerup and
>> + powerdown process.
>>  endmenu
>> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
>> index 

[PATCH V4 09/10] drm/bridge: Add ps8622/ps8625 bridge driver

[Ajay kumar]

Hi Javier,

Thanks for the review.

On Mon, Jun 23, 2014 at 12:05 PM, Javier Martinez Canillas
 wrote:
> Hello Ajay,
>
> On Wed, Jun 11, 2014 at 8:27 PM, Ajay Kumar  
> wrote:
>> From: Vincent Palatin 
>>
>> This patch adds drm_bridge driver for parade DisplayPort
>> to LVDS bridge chip.
>>
>> Signed-off-by: Vincent Palatin 
>> Signed-off-by: Andrew Bresticker 
>> Signed-off-by: Sean Paul 
>> Signed-off-by: Rahul Sharma 
>> Signed-off-by: Ajay Kumar 
>> ---
>>  .../devicetree/bindings/drm/bridge/ps8622.txt  |   21 +
>>  drivers/gpu/drm/bridge/Kconfig |8 +
>>  drivers/gpu/drm/bridge/Makefile|1 +
>>  drivers/gpu/drm/bridge/ps8622.c|  475 
>> 
>>  include/drm/bridge/ps8622.h|   41 ++
>>  5 files changed, 546 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/drm/bridge/ps8622.txt
>>  create mode 100644 drivers/gpu/drm/bridge/ps8622.c
>>  create mode 100644 include/drm/bridge/ps8622.h
>>
>> diff --git a/Documentation/devicetree/bindings/drm/bridge/ps8622.txt 
>> b/Documentation/devicetree/bindings/drm/bridge/ps8622.txt
>> new file mode 100644
>> index 000..1afbd9c
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/drm/bridge/ps8622.txt
>> @@ -0,0 +1,21 @@
>> +ps8622-bridge bindings
>> +
>> +Required properties:
>> +   - compatible: "parade,ps8622"
>> +   - reg: first i2c address of the bridge
>> +   - sleep-gpio: OF device-tree gpio specification
>> +   - reset-gpio: OF device-tree gpio specification
>> +
>> +Optional properties:
>> +   - lane-count: number of DP lanes to use
>> +   - use-external-pwm: backlight will be controlled by an external PWM
>> +
>> +Example:
>> +   ps8622-bridge at 48 {
>> +   compatible = "parade,ps8622";
>> +   reg = <0x48>;
>> +   sleep-gpio = < 6 1 0 0>;
>> +   reset-gpio = < 1 1 0 0>;
>> +   display-timings = <_display_timings>;
>> +   lane-count = <1>
>> +   };
>> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
>> index e3fb487..7b843c8 100644
>> --- a/drivers/gpu/drm/bridge/Kconfig
>> +++ b/drivers/gpu/drm/bridge/Kconfig
>> @@ -10,3 +10,11 @@ config DRM_PANEL_BINDER
>> select DRM_KMS_HELPER
>> select DRM_PANEL
>> ---help---
>> +
>> +config DRM_PS8622
>> +   tristate "Parade eDP/LVDS bridge"
>> +   depends on DRM
>> +   select DRM_KMS_HELPER
>> +   select BACKLIGHT_LCD_SUPPORT
>> +   select BACKLIGHT_CLASS_DEVICE
>> +   ---help---
>> diff --git a/drivers/gpu/drm/bridge/Makefile 
>> b/drivers/gpu/drm/bridge/Makefile
>> index ba8b5b8..b494d4b 100644
>> --- a/drivers/gpu/drm/bridge/Makefile
>> +++ b/drivers/gpu/drm/bridge/Makefile
>> @@ -2,3 +2,4 @@ ccflags-y := -Iinclude/drm
>>
>>  obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
>>  obj-$(CONFIG_DRM_PANEL_BINDER) += panel_binder.o
>> +obj-$(CONFIG_DRM_PS8622) += ps8622.o
>> diff --git a/drivers/gpu/drm/bridge/ps8622.c 
>> b/drivers/gpu/drm/bridge/ps8622.c
>> new file mode 100644
>> index 000..387d332
>> --- /dev/null
>> +++ b/drivers/gpu/drm/bridge/ps8622.c
>> @@ -0,0 +1,475 @@
>> +/*
>> + * Parade PS8622 eDP/LVDS bridge driver
>> + *
>> + * Copyright (C) 2014 Google, Inc.
>> + *
>> + * This software is licensed under the terms of the GNU General Public
>> + * License version 2, as published by the Free Software Foundation, and
>> + * may be copied, distributed, and modified under those terms.
>> + *
>> + * 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.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "drmP.h"
>> +#include "drm_crtc.h"
>> +#include "drm_crtc_helper.h"
>> +
>> +struct ps8622_bridge {
>> +   struct drm_bridge *bridge;
>> +   struct drm_encoder *encoder;
>> +   struct i2c_client *client;
>> +   struct regulator *v12;
>> +   struct backlight_device *bl;
>> +   struct mutex enable_mutex;
>> +
>> +   int gpio_slp_n;
>> +   int gpio_rst_n;
>> +
>> +   u8 max_lane_count;
>> +   u8 lane_count;
>> +
>> +   bool enabled;
>> +};
>> +
>> +struct ps8622_device_data {
>> +   u8 max_lane_count;
>> +};
>> +
>> +static const struct ps8622_device_data ps8622_data = {
>> +   .max_lane_count = 1,
>> +};
>> +
>> +static const struct ps8622_device_data ps8625_data = {
>> +   .max_lane_count = 2,
>> +};
>> +
>> +/* Brightness scale on the Parade chip */
>> +#define PS8622_MAX_BRIGHTNESS 0xff
>> +
>> +/* Timings taken from the version 1.7 datasheet for the PS8622/PS8625 */
>> +#define PS8622_POWER_RISE_T1_MIN_US 10
>> +#define 

[Bug 80419] XCOM: Enemy Unknown Causes lockup

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

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

--- Comment #2 from theamazingjanet at googlemail.com ---
Created attachment 101631
  --> https://bugs.freedesktop.org/attachment.cgi?id=101631=edit
X log

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140624/7d81985c/attachment.html>

[Bug 80419] XCOM: Enemy Unknown Causes lockup

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

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

--- Comment #1 from Michel D?nzer  ---
Please attach /var/log/Xorg.0.log and the output of dmesg and glxinfo.

> AMD HD7770 2GB
> Mesa 10.1.3

Which version of LLVM? Might be worth trying Mesa 10.2 or even current Git
master if possible.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140624/d0529230/attachment.html>

[Bug 80141] Fails to page flip multiple time, queue overflows waiting for one to finish that never does crashing entire system.

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

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

--- Comment #7 from Michel D?nzer  ---
(In reply to comment #6)
> Xorg error reporting file, has a backtrace of the fault.

Thanks, but those backtraces are not useful for doing anything about the
problem: They just show that the X server's input queue is overflowing, because
the GPU is hanging.

Have you been able yet to find an older kernel where the problem doesn't occur?
With 3.15 or newer, might be worth trying the patches from
http://lists.freedesktop.org/archives/dri-devel/2014-June/062245.html .

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140624/65f7c61b/attachment.html>

[Bug 78453] [HAWAII] Get acceleration working

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

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

--- Comment #75 from Michel D?nzer  ---
(In reply to comment #74)
> Ok, but how do I make sure that si_get_backend_mask() gets information from
> the kernel ?

By tracing its execution flow, either in gdb or by adding debugging printfs.


> > Also, might be worth testing with R600_DEBUG=nodma for now, to prevent the
> > userspace code from using the asynchronous DMA engine.
> Will do that.

Actually, that was a red herring, sorry; there's no asynchronous DMA support
yet for CIK.


> LLVM triggered Diagnostic Handler: unsupported call to function
> llvm.AMDGPU.rsq. in main

You need to update your LLVM SVN/Git snapshot.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140624/e3b29061/attachment-0001.html>

[Bug 79773] Enabling DPM results in crash for R270X PITCAIRN

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

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

--- Comment #7 from Gustavo Lopes  ---
Probably this is the same problem I reported here (exact same model):
https://bugs.freedesktop.org/show_bug.cgi?id=76490

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140624/12fd4560/attachment.html>

[Bug 76490] Hang during boot when DPM is on (R9 270X)

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

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

--- Comment #14 from Gustavo Lopes  ---
Still present in 3.16-rc2:
https://gist.github.com/cataphract/29a7c132ef4c240e9330
(last message varies; in my other try it got a little further but the log
started later as well)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: