[PATCH 4/4] drm/radeon: tweak ACCEL_WORKING2 query for the new firmware for hawaii

[Andreas Boll]

Adjust the previous tweak for hawaii to return 3 if the new firmware is used.

Signed-off-by: Andreas Boll 
---
 drivers/gpu/drm/radeon/radeon_kms.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
b/drivers/gpu/drm/radeon/radeon_kms.c
index c1a206d..eb7164d 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -255,10 +255,14 @@ static int radeon_info_ioctl(struct drm_device *dev, void 
*data, struct drm_file
break;
case RADEON_INFO_ACCEL_WORKING2:
if (rdev->family == CHIP_HAWAII) {
-   if (rdev->accel_working)
-   *value = 2;
-   else
+   if (rdev->accel_working) {
+   if (rdev->new_fw)
+   *value = 3;
+   else
+   *value = 2;
+   } else {
*value = 0;
+   }
} else {
*value = rdev->accel_working;
}
-- 
2.0.1

[PATCH 3/4] drm/radeon: use packet3 for nop on hawaii with new firmware

[Andreas Boll]

From: Alex Deucher 

Older firmware didn't support the new nop packet.

Signed-off-by: Alex Deucher 
Signed-off-by: Andreas Boll 
---
 drivers/gpu/drm/radeon/cik.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index e5985d5..8b580dc 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -8035,7 +8035,10 @@ static int cik_startup(struct radeon_device *rdev)
cik_irq_set(rdev);

if (rdev->family == CHIP_HAWAII) {
-   nop = RADEON_CP_PACKET2;
+   if (rdev->new_fw)
+   nop = PACKET3(PACKET3_NOP, 0x3FFF);
+   else
+   nop = RADEON_CP_PACKET2;
} else {
nop = PACKET3(PACKET3_NOP, 0x3FFF);
}
-- 
2.0.1

[PATCH 2/4] drm/radeon: tweak ACCEL_WORKING2 query for hawaii

[Andreas Boll]

From: Alex Deucher 

Return 2 so we can be sure the kernel has the necessary
changes for acceleration to work.

Note: This patch depends on these two commits:
 - drm/radeon: fix cut and paste issue for hawaii.
 - drm/radeon: use packet2 for nop on hawaii with old firmware

Signed-off-by: Alex Deucher 
Signed-off-by: Andreas Boll 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/radeon_kms.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
b/drivers/gpu/drm/radeon/radeon_kms.c
index d25ae6a..c1a206d 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -254,7 +254,14 @@ static int radeon_info_ioctl(struct drm_device *dev, void 
*data, struct drm_file
}
break;
case RADEON_INFO_ACCEL_WORKING2:
-   *value = rdev->accel_working;
+   if (rdev->family == CHIP_HAWAII) {
+   if (rdev->accel_working)
+   *value = 2;
+   else
+   *value = 0;
+   } else {
+   *value = rdev->accel_working;
+   }
break;
case RADEON_INFO_TILING_CONFIG:
if (rdev->family >= CHIP_BONAIRE)
-- 
2.0.1

[PATCH 1/4] drm/radeon: use packet2 for nop on hawaii with old firmware

[Andreas Boll]

From: Alex Deucher 

Older firmware didn't support the new nop packet.

v2 (Andreas Boll):
 - Drop usage of packet3 for new firmware

Signed-off-by: Alex Deucher 
Reviewed-by: Christian K?nig  (v1)
Signed-off-by: Andreas Boll 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/cik.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index c0ea661..e5985d5 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -7900,6 +7900,7 @@ restart_ih:
 static int cik_startup(struct radeon_device *rdev)
 {
struct radeon_ring *ring;
+   u32 nop;
int r;

/* enable pcie gen2/3 link */
@@ -8033,9 +8034,15 @@ static int cik_startup(struct radeon_device *rdev)
}
cik_irq_set(rdev);

+   if (rdev->family == CHIP_HAWAII) {
+   nop = RADEON_CP_PACKET2;
+   } else {
+   nop = PACKET3(PACKET3_NOP, 0x3FFF);
+   }
+
ring = >ring[RADEON_RING_TYPE_GFX_INDEX];
r = radeon_ring_init(rdev, ring, ring->ring_size, 
RADEON_WB_CP_RPTR_OFFSET,
-PACKET3(PACKET3_NOP, 0x3FFF));
+nop);
if (r)
return r;

@@ -8043,7 +8050,7 @@ static int cik_startup(struct radeon_device *rdev)
/* type-2 packets are deprecated on MEC, use type-3 instead */
ring = >ring[CAYMAN_RING_TYPE_CP1_INDEX];
r = radeon_ring_init(rdev, ring, ring->ring_size, 
RADEON_WB_CP1_RPTR_OFFSET,
-PACKET3(PACKET3_NOP, 0x3FFF));
+nop);
if (r)
return r;
ring->me = 1; /* first MEC */
@@ -8054,7 +8061,7 @@ static int cik_startup(struct radeon_device *rdev)
/* type-2 packets are deprecated on MEC, use type-3 instead */
ring = >ring[CAYMAN_RING_TYPE_CP2_INDEX];
r = radeon_ring_init(rdev, ring, ring->ring_size, 
RADEON_WB_CP2_RPTR_OFFSET,
-PACKET3(PACKET3_NOP, 0x3FFF));
+nop);
if (r)
return r;
/* dGPU only have 1 MEC */
-- 
2.0.1

[PATCH 09/19] drm/radeon: handle lockup in delayed work, v2

[Maarten Lankhorst]

On 01-08-14 18:35, Christian K?nig wrote:
> Am 31.07.2014 um 17:33 schrieb Maarten Lankhorst:
>> Signed-off-by: Maarten Lankhorst 
>> ---
>> V1 had a nasty bug breaking gpu lockup recovery. The fix is not
>> allowing radeon_fence_driver_check_lockup to take exclusive_lock,
>> and kill it during lockup recovery instead.
> 
> That looks like the delayed work starts running as soon as we submit a fence, 
> and not when it's needed for waiting.
> 
> Since it's a backup for failing IRQs I would rather put it into 
> radeon_irq_kms.c and start/stop it when the IRQs are started/stoped.

The delayed work is not just for failing irq's, it's also the handler that's 
used to detect lockups, which is why I trigger after processing fences, and 
reset the timer after processing.

Specifically what happened was this scenario:

- lock up occurs
- write lock taken by gpu_reset
- delayed work runs, tries to acquire read lock, blocks
- gpu_reset tries to cancel delayed work synchronously
- has to wait for delayed work to finish -> deadlock

~Maarten

[PATCH 17/19] drm/radeon: use rcu waits in some ioctls

[Maarten Lankhorst]

On 01-08-14 16:13, Michel D?nzer wrote:
> On 01.08.2014 19:12, Maarten Lankhorst wrote:
>> Hey,
>>
>> On 01-08-14 10:27, Michel D?nzer wrote:
>>> On 01.08.2014 00:34, Maarten Lankhorst wrote:

 @@ -357,14 +360,20 @@ int radeon_gem_wait_idle_ioctl(struct drm_device 
 *dev, void *data,
struct drm_radeon_gem_wait_idle *args = data;
struct drm_gem_object *gobj;
struct radeon_bo *robj;
 -  int r;
 +  int r = 0;
 +  long ret;
  
gobj = drm_gem_object_lookup(dev, filp, args->handle);
if (gobj == NULL) {
return -ENOENT;
}
robj = gem_to_radeon_bo(gobj);
 -  r = radeon_bo_wait(robj, NULL, false);
 +  ret = reservation_object_wait_timeout_rcu(robj->tbo.resv, true, true, 
 30 * HZ);
 +  if (ret == 0)
 +  r = -EBUSY;
 +  else if (ret < 0)
 +  r = ret;
 +
/* callback hw specific functions if any */
if (rdev->asic->ioctl_wait_idle)
robj->rdev->asic->ioctl_wait_idle(rdev, robj);
>>>
>>> Heads up, this conflicts with
>>> http://lists.freedesktop.org/archives/dri-devel/2014-August/065255.html
>>> which passes a non-NULL second argument to radeon_bo_wait() to get the
>>> BO's current domain.
>> Ok, I will fix it up and resend it later.
>>
>> Does it matter if I grab the current domain without grabbing the lock
>> here? Because it doesn't matter if it sees the old or new domain, it
>> could have been changed after returning too.
> 
> It should be the domain where the BO is located when the fence we are
> waiting for here signals.
Could we compare domain before and after the rcu wait, and retry waiting if 
they're different, and the new one is VRAM? (eg eviction happened) That should 
prevent needing to lock the bo.

~Maarten

[PATCH 09/19] drm/radeon: handle lockup in delayed work, v2

[Christian König]

Am 31.07.2014 um 17:33 schrieb Maarten Lankhorst:
> Signed-off-by: Maarten Lankhorst 
> ---
> V1 had a nasty bug breaking gpu lockup recovery. The fix is not
> allowing radeon_fence_driver_check_lockup to take exclusive_lock,
> and kill it during lockup recovery instead.

That looks like the delayed work starts running as soon as we submit a 
fence, and not when it's needed for waiting.

Since it's a backup for failing IRQs I would rather put it into 
radeon_irq_kms.c and start/stop it when the IRQs are started/stoped.

Christian.

> ---
>   drivers/gpu/drm/radeon/radeon.h|3 +
>   drivers/gpu/drm/radeon/radeon_device.c |5 +
>   drivers/gpu/drm/radeon/radeon_fence.c  |  124 
> ++--
>   drivers/gpu/drm/radeon/radeon_ring.c   |1
>   4 files changed, 77 insertions(+), 56 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index 60c47f829122..b01d88fc10cb 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -347,6 +347,8 @@ struct radeon_fence_driver {
>   uint64_tsync_seq[RADEON_NUM_RINGS];
>   atomic64_t  last_seq;
>   boolinitialized;
> + struct delayed_work fence_check_work;
> + struct radeon_device*rdev;
>   };
>   
>   struct radeon_fence {
> @@ -360,6 +362,7 @@ struct radeon_fence {
>   
>   int radeon_fence_driver_start_ring(struct radeon_device *rdev, int ring);
>   int radeon_fence_driver_init(struct radeon_device *rdev);
> +void radeon_fence_cancel_delayed_check(struct radeon_device *rdev, int ring);
>   void radeon_fence_driver_fini(struct radeon_device *rdev);
>   void radeon_fence_driver_force_completion(struct radeon_device *rdev);
>   int radeon_fence_emit(struct radeon_device *rdev, struct radeon_fence 
> **fence, int ring);
> diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
> b/drivers/gpu/drm/radeon/radeon_device.c
> index 697add2cd4e3..21efd32d07ee 100644
> --- a/drivers/gpu/drm/radeon/radeon_device.c
> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> @@ -1637,6 +1637,11 @@ int radeon_gpu_reset(struct radeon_device *rdev)
>   radeon_save_bios_scratch_regs(rdev);
>   /* block TTM */
>   resched = ttm_bo_lock_delayed_workqueue(>mman.bdev);
> +
> + /* kill all the hangcheck tests too */
> + for (i = 0; i < RADEON_NUM_RINGS; ++i)
> + radeon_fence_cancel_delayed_check(rdev, i);
> +
>   radeon_pm_suspend(rdev);
>   radeon_suspend(rdev);
>   
> diff --git a/drivers/gpu/drm/radeon/radeon_fence.c 
> b/drivers/gpu/drm/radeon/radeon_fence.c
> index 913787085dfa..c055acc3a271 100644
> --- a/drivers/gpu/drm/radeon/radeon_fence.c
> +++ b/drivers/gpu/drm/radeon/radeon_fence.c
> @@ -125,16 +125,7 @@ int radeon_fence_emit(struct radeon_device *rdev,
>   return 0;
>   }
>   
> -/**
> - * radeon_fence_process - process a fence
> - *
> - * @rdev: radeon_device pointer
> - * @ring: ring index the fence is associated with
> - *
> - * Checks the current fence value and wakes the fence queue
> - * if the sequence number has increased (all asics).
> - */
> -void radeon_fence_process(struct radeon_device *rdev, int ring)
> +static bool __radeon_fence_process(struct radeon_device *rdev, int ring)
>   {
>   uint64_t seq, last_seq, last_emitted;
>   unsigned count_loop = 0;
> @@ -190,7 +181,51 @@ void radeon_fence_process(struct radeon_device *rdev, 
> int ring)
>   }
>   } while (atomic64_xchg(>fence_drv[ring].last_seq, seq) > seq);
>   
> - if (wake)
> + if (seq < last_emitted)
> + mod_delayed_work(system_power_efficient_wq,
> +  >fence_drv[ring].fence_check_work,
> +  RADEON_FENCE_JIFFIES_TIMEOUT);
> +
> + return wake;
> +}
> +
> +static void radeon_fence_driver_check_lockup(struct work_struct *work)
> +{
> + struct radeon_fence_driver *fence_drv;
> + struct radeon_device *rdev;
> + unsigned long iring;
> +
> + fence_drv = container_of(work, struct radeon_fence_driver, 
> fence_check_work.work);
> + rdev = fence_drv->rdev;
> + iring = fence_drv - >fence_drv[0];
> +
> + if (__radeon_fence_process(rdev, iring))
> + wake_up_all(>fence_queue);
> + else if (radeon_ring_is_lockup(rdev, iring, >ring[iring])) {
> + /* good news we believe it's a lockup */
> + dev_warn(rdev->dev, "GPU lockup (current fence id "
> +  "0x%016llx last fence id 0x%016llx on ring %ld)\n",
> +  (uint64_t)atomic64_read(_drv->last_seq),
> +  fence_drv->sync_seq[iring], iring);
> +
> + /* remember that we need an reset */
> + rdev->needs_reset = true;
> + wake_up_all(>fence_queue);
> + }
> +}
> +
> +/**
> + * radeon_fence_process - process a fence
> + *
> + * @rdev: radeon_device pointer
> + * @ring: ring 

[PATCH 15/15] drm/exynos: dp: Modify driver to support drm_panel

[Inki Dae]

On 2014? 08? 01? 18:09, Thierry Reding wrote:
> On Thu, Jul 31, 2014 at 11:12:14PM +0530, Ajay Kumar wrote:
>> Add drm_panel controls to support powerup/down of the
>> eDP panel, if one is present at the sink side.
>>
>> Signed-off-by: Ajay Kumar 
>> ---
>>  drivers/gpu/drm/exynos/Kconfig  |1 +
>>  drivers/gpu/drm/exynos/exynos_dp_core.c |   88 
>> ---
>>  drivers/gpu/drm/exynos/exynos_dp_core.h |3 +-
>>  3 files changed, 71 insertions(+), 21 deletions(-)
> 
> Inki, I'll need an Acked-by from you on this one as well. It has a build
> time dependency on earlier patches in this series, so taking it through
> the panel tree along with the rest is probably easiest.

Acked-by: Inki Dae 

Thanks,
Inki Dae

> 
> Thierry
> 

[PATCH 06/15] drm/exynos: dpi: Add support for panel prepare and unprepare routines

[Inki Dae]

On 2014? 08? 01? 18:04, Thierry Reding wrote:
> On Thu, Jul 31, 2014 at 11:12:05PM +0530, Ajay Kumar wrote:
>> Modify exynos_dpi driver to support the new panel calls:
>> prepare and unprepare.
>>
>> Signed-off-by: Ajay Kumar 
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_dpi.c |8 ++--
>>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> Looks good to me. Inki, can I have your Acked-by to take this through
> the panel tree?

Of course.

Acked-by: Inki Dae 

Thanks,
Inki Dae

> 
> Thierry
> 

[Bug 82019] Unreal Engine Effects Cave demo lockup HD 7970M

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

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

--- Comment #2 from Christoph Haag  ---
Created attachment 103827
  --> https://bugs.freedesktop.org/attachment.cgi?id=103827=edit
another dmesg with 3.16-rc7 and nodma

Tried with: DRI_PRIME=1 GALLIUM_HUD="fps,VRAM-usage+GTT-usage"
RADEON_DEBUG=nodma ./Effects

I didn't see much of a difference.

-- 
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/20140801/2c89874e/attachment-0001.html>

[Bug 82019] Unreal Engine Effects Cave demo lockup HD 7970M

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

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

--- Comment #1 from Alex Deucher  ---
Does setting env var RADEON_DEBUG=nodma help?

-- 
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/20140801/d13d169d/attachment.html>

[PATCH 17/19] drm/radeon: use rcu waits in some ioctls

[Michel Dänzer]

On 01.08.2014 00:34, Maarten Lankhorst wrote:
> 
> @@ -357,14 +360,20 @@ int radeon_gem_wait_idle_ioctl(struct drm_device *dev, 
> void *data,
>   struct drm_radeon_gem_wait_idle *args = data;
>   struct drm_gem_object *gobj;
>   struct radeon_bo *robj;
> - int r;
> + int r = 0;
> + long ret;
>  
>   gobj = drm_gem_object_lookup(dev, filp, args->handle);
>   if (gobj == NULL) {
>   return -ENOENT;
>   }
>   robj = gem_to_radeon_bo(gobj);
> - r = radeon_bo_wait(robj, NULL, false);
> + ret = reservation_object_wait_timeout_rcu(robj->tbo.resv, true, true, 
> 30 * HZ);
> + if (ret == 0)
> + r = -EBUSY;
> + else if (ret < 0)
> + r = ret;
> +
>   /* callback hw specific functions if any */
>   if (rdev->asic->ioctl_wait_idle)
>   robj->rdev->asic->ioctl_wait_idle(rdev, robj);

Heads up, this conflicts with
http://lists.freedesktop.org/archives/dri-devel/2014-August/065255.html
which passes a non-NULL second argument to radeon_bo_wait() to get the
BO's current domain.


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

[PATCH] drm/radeon: Only flush HDP cache from idle ioctl if BO is in VRAM

[Michel Dänzer]

From: Michel D?nzer 

The HDP cache only applies to CPU access to VRAM.

Signed-off-by: Michel D?nzer 
---
 drivers/gpu/drm/radeon/radeon_gem.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_gem.c 
b/drivers/gpu/drm/radeon/radeon_gem.c
index a350cf9..8f2cb58 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -359,15 +359,17 @@ int radeon_gem_wait_idle_ioctl(struct drm_device *dev, 
void *data,
struct drm_gem_object *gobj;
struct radeon_bo *robj;
int r;
+   uint32_t cur_placement = 0;

gobj = drm_gem_object_lookup(dev, filp, args->handle);
if (gobj == NULL) {
return -ENOENT;
}
robj = gem_to_radeon_bo(gobj);
-   r = radeon_bo_wait(robj, NULL, false);
+   r = radeon_bo_wait(robj, _placement, false);
/* Flush HDP cache via MMIO if necessary */
-   if (rdev->asic->mmio_hdp_flush)
+   if (rdev->asic->mmio_hdp_flush &&
+   radeon_mem_type_to_domain(cur_placement) == RADEON_GEM_DOMAIN_VRAM)
robj->rdev->asic->mmio_hdp_flush(rdev);
drm_gem_object_unreference_unlocked(gobj);
r = radeon_gem_handle_lockup(rdev, r);
-- 
2.0.1

[GIT PULL] TDA998x I2C driver updates

[Russell King]

David,

Please incorporate the latest TDA998x I2C driver updates, which can be found at:

  git://ftp.arm.linux.org.uk/~rmk/linux-cubox.git tda998x-devel

with SHA1 c707c3619ca81f499a5ce032021405e989a96ff0.

This builds upon the previous set of fixes which were pulled on 6th July.
Included in this set are:
- an update from Jean-Francois to add the missing reg documentation entry
  to the device tree documentation.
- conversion of the tda998x driver to the component helpers.

This will update the following files:

 .../devicetree/bindings/drm/i2c/tda998x.txt|   2 +
 drivers/gpu/drm/i2c/tda998x_drv.c  | 387 -
 2 files changed, 308 insertions(+), 81 deletions(-)

through these changes:

Jean-Francois Moine (1):
  drm/i2c: tda998x: fix lack of required reg in DT documentation

Russell King (2):
  drm/i2c: tda998x: allow re-use of tda998x support code
  drm/i2c: tda998x: add component support

Many thanks.

[Bug 82019] New: Unreal Engine Effects Cave demo lockup HD 7970M

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

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

  Priority: medium
Bug ID: 82019
  Assignee: dri-devel at lists.freedesktop.org
   Summary: Unreal Engine Effects Cave demo lockup HD 7970M
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: haagch at frickel.club
  Hardware: Other
Status: NEW
   Version: git
 Component: Drivers/Gallium/radeonsi
   Product: Mesa

Created attachment 103826
  --> https://bugs.freedesktop.org/attachment.cgi?id=103826=edit
full dmesg with lockup

On my ivy bridge/HD 7970M hybrid laptop, started with

DRI_PRIME=1 GALLIUM_HUD="fps,VRAM-usage+GTT-usage" ./Effects
so no hyperz.

mesa git with f4b0ab7afd83c811329211eae8167c9bf238870c reverted because of bug
81834 and with 0001-glsl-support-unsigned-increment-in-ir_loop.patch from
https://bugs.freedesktop.org/show_bug.cgi?id=80880#c10

On reddit someone with a HD 7790 said it works
(http://www.reddit.com/r/linux_gaming/comments/2cbspp/unreal_engine_4_starts_working_on_the_radeonsi/cjdzh2v)

For me with my HD 7970M it produces this hang on both 3.16-rc7 and
agd5f/drm-next-3.17-rebased-on-fixes:

ring 3 stalled for more than 10296msec
GPU lockup (waiting for 0x0cdc last fence id 0x0cdb on
ring 3)
scheduling IB failed (-35).
Saved 525 dwords of commands on ring 0.
GPU softreset: 0x004D
  GRBM_STATUS   = 0xE7DE5028
  GRBM_STATUS_SE0   = 0xEF82
  GRBM_STATUS_SE1   = 0xEFC2
  SRBM_STATUS   = 0x20C0
  SRBM_STATUS2  = 0x
  R_008674_CP_STALLED_STAT1 = 0x
  R_008678_CP_STALLED_STAT2 = 0x00010800
  R_00867C_CP_BUSY_STAT = 0x00408006
  R_008680_CP_STAT  = 0x84038647
  R_00D034_DMA_STATUS_REG   = 0x45483106
  R_00D834_DMA_STATUS_REG   = 0x44C83D57
  VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x
  VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x
GRBM_SOFT_RESET=0xDDFF
SRBM_SOFT_RESET=0x00100100
  GRBM_STATUS   = 0x3028
  GRBM_STATUS_SE0   = 0x0006
  GRBM_STATUS_SE1   = 0x0006
  SRBM_STATUS   = 0x20C0
  SRBM_STATUS2  = 0x
  R_008674_CP_STALLED_STAT1 = 0x
  R_008678_CP_STALLED_STAT2 = 0x
  R_00867C_CP_BUSY_STAT = 0x
  R_008680_CP_STAT  = 0x
  R_00D034_DMA_STATUS_REG   = 0x44C83D57
  R_00D834_DMA_STATUS_REG   = 0x44C83D57
GPU reset succeeded, trying to resume

-- 
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/20140801/498c3d0a/attachment.html>

[PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support

[Andreas Färber]

Ajay,

Am 01.08.2014 09:02, schrieb Ajay kumar:
> On Thu, Jul 31, 2014 at 7:52 PM, Andreas F?rber  wrote:
>> Am 31.07.2014 12:23, schrieb Thierry Reding:
>>> On Thu, Jul 31, 2014 at 10:57:55AM +0200, Andreas F?rber wrote:
 Am 31.07.2014 10:38, schrieb Ajay kumar:
> With just the spring-bridge.v6 branch of your own tree, I am able to see
> bootup logo on Skate(a variant of spring which also contains ps8622).
> I have tried both exynos_defconfig and multi_v7_defconfig.
> I enable DRM, EXYNOS DRM, BRIDGE CHIPS, IOMMU, EXYNOS IOMMU
> in configs.
>> [...]
>>> If you have something like simplefb enabled in addition to a DRM driver,
>>> then perhaps the DRM driver isn't properly taking over the framebuffer
>>> console.
>>
>> So, with simplefb reverted in U-Boot and ...
>>
>> * with just the v6 applied (...~2), I get only a black screen from
>> Linux, no penguins, but the backlight seems on. System comes up okay,
>> ssh available, and nothing stands out in dmesg.
>>
>> * with the two iommu patches on top, something breaks badly, no
>> backlight, no USB/network, system inaccessible.
>> I.e. U-Boot had no noticeable impact on these symptoms.
>>
>> * with the iommu patches, but dp-controller, ps8622, panel commented
>> out, I do get backlight but USB/network not working, system inaccessible.
>>
>> With simplefb support in U-Boot and with just v6 applied, but
>> dp-controller, ps8622, panel commented out, things work as well as
>> before, i.e. this series has no bad side effects. Note that I never
>> claimed Ajay's series were broken, just reported that things regressed
>> for me from v4, which may well be DT-related.
>>
>> The iommu patches interfere with my USB somehow (none or not all devices
>> powered; with v4, plugging my wifi dongle led to oops but ethernet
>> dongle worked, so not entirely new symptom), which is bad since my
>> rootfs is on USB. The internal SDIO-connected Wifi is not enabled yet,
>> so USB based network is my only alternative to a working display once we
>> reach userspace.
> Well, there are 2 variants here:
> 1) Bootloader
> 2) config

Unfortunately your config doesn't work for me either, on my latest
spring-bridge.v6 branch.

> Type of the bootloader should not matter unless its switching on
> FET1 and FET6 of tps65090 for you.

It does switch them on, if I'm reading correctly:

https://github.com/afaerber/u-boot/blob/spring/board/samsung/smdk5250/smdk5250.c#L599

https://github.com/afaerber/u-boot/blob/spring/board/samsung/smdk5250/smdk5250.c#L907

Another observation I made is that sometimes in my testing (didn't spot
a pattern yet) after reboot or power-off/power-on the initial white
screen with the warning did not come up (no backlight), but Ctrl+U
worked fine and chain-loaded nv u-boot came up on screen okay.

Andreas

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

[Bug 74250] [HAWAII][DPM] New Version 3.1 for ASIC_ProfilingInfo / ci_upload_dpm_level_enable_mask failed

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

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

--- Comment #7 from Alex Deucher  ---
(In reply to comment #6)
> (In reply to comment #4)
> > Please try the attached patches.
> 
> Yay, those help ! Thanks a lot, Alex ! :-)
> With all three patches (attachements #93015, #103772, #103773) I get working
> DPM and none of the error messages above.
> I used the drm-next-3.17-wip kernel from yesterday with the patches applied
> manually (noticed you committed them just after I started the build). I
> think you didn't commit #93015 ?

It's irrelevant with the other patches applied.

> DPM also seems to work quite correcty, the card goes up to over 1GHz
> (1040MHz should be max for my card) on sclk, mclk always stays the same (but
> is different than without dpm):
> # cat /sys/kernel/debug/dri/0/radeon_pm_info
> power level avgsclk: 100120 mclk: 13
> 
> Without the patches, I always got:
> power level avgsclk: 3 mclk: 15000
> 
> Half-Life 2 now runs more or less constantly at 60fps with hig details and
> 8x MSAA :-) Metro Last Light is only at 20-30fps, but that's still great.
> What I don't really understand is that Metro didn't feel much slower when
> dpm didn't work (HL2 certainly did).
> 
> 
> I guess sclk stands for "shader clock" and mclk is for "memory clock" ? On
> Windows I believe I also have different memory clocks between the desktop
> and in games - is memory clocking not dynamic yet ?

sclk (system clock) is the engine clock and mclk is the memory clock.  It
should be dynamic.  With no GPU tasks running you should see power
level avgsclk: 3 mclk: 15000
and both should be higher when there is GPU load.  Can you attach your dmesg
and xorg log with the patches applied?  Also are you using multiple monitors? 
If so can you try again with a single monitor?

-- 
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/20140801/573d4f1b/attachment.html>

[Bug 74250] [HAWAII][DPM] New Version 3.1 for ASIC_ProfilingInfo / ci_upload_dpm_level_enable_mask failed

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

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

--- Comment #6 from Luzipher  ---
(In reply to comment #4)
> Please try the attached patches.

Yay, those help ! Thanks a lot, Alex ! :-)
With all three patches (attachements #93015, #103772, #103773) I get working
DPM and none of the error messages above.
I used the drm-next-3.17-wip kernel from yesterday with the patches applied
manually (noticed you committed them just after I started the build). I think
you didn't commit #93015 ?

I also tried without attachment #93015, but I can't really explain the results.
I expected to see the "*ERROR* Unknown table version 3, 1" message, but it
didn't show up. Still dpm didn't work and I did get the "*ERROR*
ci_upload_dpm_level_enable_mask failed" message.

DPM also seems to work quite correcty, the card goes up to over 1GHz (1040MHz
should be max for my card) on sclk, mclk always stays the same (but is
different than without dpm):
# cat /sys/kernel/debug/dri/0/radeon_pm_info
power level avgsclk: 100120 mclk: 13

Without the patches, I always got:
power level avgsclk: 3 mclk: 15000

Half-Life 2 now runs more or less constantly at 60fps with hig details and 8x
MSAA :-) Metro Last Light is only at 20-30fps, but that's still great. What I
don't really understand is that Metro didn't feel much slower when dpm didn't
work (HL2 certainly did).


I guess sclk stands for "shader clock" and mclk is for "memory clock" ? On
Windows I believe I also have different memory clocks between the desktop and
in games - is memory clocking not dynamic 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/20140801/b867c387/attachment.html>

[PATCH] radeon: allow write_reloc with unaccounted buffers to cope with Mesa R200 bug

[Marek Olšák]

From: Marek Ol??k 

---

I'm not really interested in studying the R200 driver to fix it.
This has to suffice.

 radeon/radeon_cs_gem.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/radeon/radeon_cs_gem.c b/radeon/radeon_cs_gem.c
index b87c6b1..bcfa05b 100644
--- a/radeon/radeon_cs_gem.c
+++ b/radeon/radeon_cs_gem.c
@@ -178,6 +178,15 @@ static int cs_gem_write_reloc(struct radeon_cs_int *cs,
 uint32_t idx;
 unsigned i;

+if (!boi->space_accounted) {
+struct radeon_cs *rcs = (struct radeon_cs*)cs;
+int r;
+
+radeon_cs_space_add_persistent_bo(rcs, bo, read_domain, write_domain);
+r = radeon_cs_space_check(rcs);
+if (r)
+return r;
+}
 assert(boi->space_accounted);

 /* check domains */
-- 
1.9.1

Re: [Radeon RV280] radeon_cs_gem.c:181: cs_gem_write_reloc: Assertion »boi->space_accounted« failed, core dumped

[Jochen Rollwagen]

The patch does indeed fix the crashes. The cutscenes run through now 
without problems.

Thank you very much.

Am 01.08.2014 um 13:36 schrieb Marek Ol??k:
> Does the attached libdrm patch fix the issue for you?
>
> Marek
>
> On Fri, Aug 1, 2014 at 1:16 PM, Marek Ol??k  wrote:
>> Not in this case. You added a fail path to a function which isn't
>> supposed to fail under these circumstances. No wonder Mesa couldn't
>> cope with it. It really has nothing to do with your original issue.
>>
>> Marek
>>
>> On Fri, Aug 1, 2014 at 9:25 AM, Jochen Rollwagen  
>> wrote:
>>> I've built the latest libdrm and replaced the assertion in radeon_cs_gem.c.
>>> with
>>>
>>> if (!boi->space_accounted) return -EINVAL;
>>>
>>> I now get the following crash in the cutscene:
>>>
>>>
>>> CS section size missmatch start at (r200_state_init.c,ctx_emit_cs,487) 28 vs
>>> 24
>>> CS section end at (r200_state_init.c,ctx_emit_cs,520)
>>> CS section size missmatch start at (r200_state_init.c,tex_emit_mm,572) 13 vs
>>> 11
>>> CS section end at (r200_state_init.c,tex_emit_mm,588)
>>> drmRadeonCmdBuffer: -22. Kernel failed to parse or rejected command stream.
>>> See dmesg for more info.
>>>
>>>
>>> dmesg output is:
>>>
>>> [ 1232.744676] [drm:radeon_cs_packet_next_reloc] *ERROR* No packet3 for
>>> relocati
>>> on for packet at 34.
>>> [ 1232.744691] [drm] ib[34]=0x0712
>>> [ 1232.744694] [drm] ib[35]=0x00010340
>>> [ 1232.744698] [drm:r200_packet0_check] *ERROR* No reloc for ib[33]=0x1C40
>>> [ 1232.744701] [drm] ib[32]=0x0710
>>> [ 1232.744704] [drm] ib[33]=0x
>>> [ 1232.744707] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
>>>
>>> So it's really a mesa bug :-(
>>>
>>>
>>>
>>> Am 27.07.2014 um 14:47 schrieb Marek Ol??k:
 I think the problem is the driver hasn't called

 radeon_cs_space_add_persistent_bo.

 Marek

 On Fri, Jul 25, 2014 at 6:32 PM, Jochen Rollwagen >>> t-online.de>
 wrote:
> I've recently ported the peopsxgl OpenGL-GPU-Plugin for the pcsx
> Playstation1 Emulator to the Powerpc-architecture. When running certain
> games (for instance "Vagrant Stories") during longer cut-scenes i get a
> reproducible crash of the radeon drm driver (i.e. it always crashes at
> certain points in the scene) with the following message (in german):
>
> pcsx: radeon_cs_gem.c:181: cs_gem_write_reloc: Zusicherung
> ?boi->space_accounted? nicht erf?llt.
> Abgebrochen (Speicherabzug geschrieben)
>
> This happens with all the latest 3.10, 3.12 and 3.14 kernels.
>
> Other than that i'm running the latest xorg-ati driver, libdrm and mesa
> from
> git on a Mac Mini G4 (PowerPC).
>
> OpenGL vendor string: Mesa Project
> OpenGL renderer string: Mesa DRI R200 (RV280 5962)  TCL DRI2
> OpenGL version string: 1.3 Mesa 10.1.6 (git-42f86ef)
>
> I guess the issue is memory/vm/swap-related since the machine only has 1
> gb
> RAM. The GPU has 64 MB VRAM.
>
> Any ideas what i could do to avoid these crashes ?
>
>
>
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>

[Bug 81907] Unreal Engine "Effects Cave" Demo crashes with SIGBUS in __memcpy_sse2_unaligned

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

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

--- Comment #3 from Christoph Haag  ---
Oh, the hang in comment 1 may have been my fault for running it with hyperz.

But without hyperz it hangs too, just less verbosely:

radeon :01:00.0: ring 3 stalled for more than 10016msec
radeon :01:00.0: GPU lockup (waiting for 0x00011c4a last fence id
0x00011b2a on ring 3)
[TTM] Buffer eviction failed

-- 
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/20140801/74a75317/attachment.html>

[PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers

[Randy Dunlap]

On 08/01/14 05:58, Laurent Pinchart wrote:
> Hi Randy,
> 
> On Thursday 31 July 2014 15:16:21 Randy Dunlap wrote:
>> On 05/12/14 11:04, Randy Dunlap wrote:
>>> On 05/12/2014 08:54 AM, Daniel Vetter wrote:
 On Mon, May 12, 2014 at 08:23:45AM -0700, Randy Dunlap wrote:
> On 05/12/2014 01:58 AM, Daniel Vetter wrote:
>> On Mon, May 12, 2014 at 06:24:57PM +1000, Dave Airlie wrote:
> If we decide to go for property documentation inside the source code
> then I believe we'll have to create our own format, as creating a
> properties table from kerneldoc information extracted from comments
> is probably not possible.

 Can comeone pick up the ball here and figure out what needs to be
 done?

 The reason why I want a central place for the documentation is to
 force people to collaborate outside their own sandbox when adding
 properties. Whether that's docbook or some text file I don't care so
 much at this point. The fact that it's a central place should mandate
 that the patches changing it will go through dri-devel and so
 everyone should se them, and when adding new properties it would make
 the patch author more likely to look around a bit before adding
 another slighty incompatible version of the same property. If someone
 has a better suggestion how to encforce this I'm all ears.

 Of course this idea can still fail if our esteemed maintainer merges
 stuff without checking for violations of this policy. Dave, any
 thoughts on the subject?
>>>
>>> Yeah I'm happy to block merging stuff, if we can spot new properties
>>> when stuff is posted on dri-devel, so much the better,
>>>
>>> most drivers still send everything via dri-devel anyways, its only
>>> really Intel I have to worry about so far,
>>
>> I'll enforce that all prop stuff gets cc: dri-devel and that it has
>> updates for the prop docs.
>>
>>> But we should definitely add it to the new driver review checklist as
>>> well.
>>>
>>> I'm also on the side of this patch is ugly and makes my eyes burn,
>>> please please get a plan to use something else ASAP, I'm willing to
>>> merge this but I'm tempted to give it a lifetime of a kernel or two
>>> before I burn it.
>>
>> Ok, I'll try to move "make kerneldoc suck less" up the task list and
>> maybe find someone to do it for me internally ;-)
>
> I certainly have no objections to making kerneldoc suck less.
> There was already an attempt to use asciidoc (like git uses) for
> kernel-doc (a few years ago, by Sam Ravnborg).  I support(ed) that
> effort.

 Hm, do you have pointers to those? My google-fu seems lacking ...
>>>
>>> I googled for /kernel doc asciidoc ravnborg/ and found several hits for
>>> them.
>>>
 Ok, let's move this to the top and start discussions. The past few months
 I've written piles of kerneldoc comments for the DRM DocBook (all pulled
 in as kerneldoc, docbook .tmpl has just the chapter structure). DOC:
 sections are really useful to pull all the actual documentation out of
 the docbook xml into kerneldoc.

 But I've also done piles of docs for intel-gpu-tools, which is using
 gtkdoc. And there are some clear deficiencies:

 - No markdown for inline coments. Lack of lists and tables is hurting
   especially badly. If we add this (and I don't care one iota whether
   it's
>>>
>>> Yes, I've tried to add lists to kernel-doc notation but have failed so
>>> far.
>>>
   markdown or asciidoc or something else as long as it's readable plain
   text in comments) we should be able to move all the existing docbook
   xml paragraphs/lists/tables into kerneldoc comments.

 - Automatic cross-referencing of functions. If you place e.g. function()
   or #struct anywhere in a documentation comment gtk-doc automatically
   inserts a hyperlink to the relevant documentation page across the
   entire project. Really powerful and makes overview sections much more
   useful entry points for beginners since they can easily jump back
   betweeen the high-level overview and low-level per-function
   documentation.
>>>
>>> That's a nice-to-have IMO, but a really nice one.
>>>
 - In a really perfect world it would help if kerneldoc could collect
   structure member kerneldoc from per-member comments. Especially for
   large structures with lots of comments this would bring the kerneldoc
   and struct member much closer together.

 So that's my wishlist.

> OTOH, I would only want to add another way to do kernel-doc if it can be
> a full replacement for all of our docbook usage, i.e., it should provide
> a way that we can eliminate docbook and stop using it completely.

 Hm, I don't mind docbook at 

[PATCH 14/15] drm/exynos: Move DP setup into commit()

[Ajay kumar]

On Fri, Aug 1, 2014 at 2:48 PM, Thierry Reding  
wrote:
> On Thu, Jul 31, 2014 at 11:12:13PM +0530, Ajay Kumar wrote:
>> Add commit callback for exynos_dp, and move the DP link training,
>> video configuration code from the hotplug handler into commit().
>>
>> Signed-off-by: Sean Paul 
>> Signed-off-by: Ajay Kumar 
>> ---
>>  drivers/gpu/drm/exynos/exynos_dp_core.c |   24 +++-
>>  1 file changed, 19 insertions(+), 5 deletions(-)
>
> This is not related to the other patches in the series, so it can be
> applied independently.
This patch should go in this series only.
[PATCH 15/15] has dependency on this because it modifies exynos_dp_commit().

> Sean, this looks like a back-/forward-port of the patch you linked to in
> reply to an earlier version of the series, does this still correspond to
> what you think it should be doing? (hence not trimming the quote)
Sean said one of his test app fails since exynos_dp_commit was missing
in previous version of this patch.
Now, I have added exynos_dp_commit as he suggested, and the side effect
because of this addition (video reconfiguration glitch) is taken care by the
panel calls in the next patch [PATCH 15/15].

Ajay

>> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
>> b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> index 31c3de9..347dec9 100644
>> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
>> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> @@ -875,10 +875,18 @@ static irqreturn_t exynos_dp_irq_handler(int irq, void 
>> *arg)
>>  static void exynos_dp_hotplug(struct work_struct *work)
>>  {
>>   struct exynos_dp_device *dp;
>> - int ret;
>>
>>   dp = container_of(work, struct exynos_dp_device, hotplug_work);
>>
>> + if (dp->drm_dev)
>> + drm_helper_hpd_irq_event(dp->drm_dev);
>> +}
>> +
>> +static void exynos_dp_commit(struct exynos_drm_display *display)
>> +{
>> + struct exynos_dp_device *dp = display->ctx;
>> + int ret;
>> +
>>   ret = exynos_dp_detect_hpd(dp);
>>   if (ret) {
>>   /* Cable has been disconnected, we're done */
>> @@ -1050,8 +1058,10 @@ static void exynos_dp_phy_exit(struct 
>> exynos_dp_device *dp)
>>   }
>>  }
>>
>> -static void exynos_dp_poweron(struct exynos_dp_device *dp)
>> +static void exynos_dp_poweron(struct exynos_drm_display *display)
>>  {
>> + struct exynos_dp_device *dp = display->ctx;
>> +
>>   if (dp->dpms_mode == DRM_MODE_DPMS_ON)
>>   return;
>>
>> @@ -1059,10 +1069,13 @@ static void exynos_dp_poweron(struct 
>> exynos_dp_device *dp)
>>   exynos_dp_phy_init(dp);
>>   exynos_dp_init_dp(dp);
>>   enable_irq(dp->irq);
>> + exynos_dp_commit(display);
>>  }
>>
>> -static void exynos_dp_poweroff(struct exynos_dp_device *dp)
>> +static void exynos_dp_poweroff(struct exynos_drm_display *display)
>>  {
>> + struct exynos_dp_device *dp = display->ctx;
>> +
>>   if (dp->dpms_mode != DRM_MODE_DPMS_ON)
>>   return;
>>
>> @@ -1078,12 +1091,12 @@ static void exynos_dp_dpms(struct exynos_drm_display 
>> *display, int mode)
>>
>>   switch (mode) {
>>   case DRM_MODE_DPMS_ON:
>> - exynos_dp_poweron(dp);
>> + exynos_dp_poweron(display);
>>   break;
>>   case DRM_MODE_DPMS_STANDBY:
>>   case DRM_MODE_DPMS_SUSPEND:
>>   case DRM_MODE_DPMS_OFF:
>> - exynos_dp_poweroff(dp);
>> + exynos_dp_poweroff(display);
>>   break;
>>   default:
>>   break;
>> @@ -1094,6 +1107,7 @@ static void exynos_dp_dpms(struct exynos_drm_display 
>> *display, int mode)
>>  static struct exynos_drm_display_ops exynos_dp_display_ops = {
>>   .create_connector = exynos_dp_create_connector,
>>   .dpms = exynos_dp_dpms,
>> + .commit = exynos_dp_commit,
>>  };
>>
>>  static struct exynos_drm_display exynos_dp_display = {
>> --
>> 1.7.9.5
>>

[Bug 79980] Random radeonsi crashes

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

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

--- Comment #84 from Andy Furniss  ---
(In reply to comment #83)
> (In reply to comment #82)
> > (In reply to comment #80)
> > > 
> > > I have got the new firmware (unless there's an even newer one) and have
> > > booted into the other 3.17 before - but it eventually crashed due to 
> > > missing
> > > fixes.
> > 
> > When did you download it?  The header format changed last week and I
> > uploaded a new version.
> 
> Ahh, it was longer ago that that, will try newer.

Booting OK with new firmware.

-- 
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/20140801/afd0459a/attachment.html>

[PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers

[Laurent Pinchart]

Hi Randy,

On Thursday 31 July 2014 15:16:21 Randy Dunlap wrote:
> On 05/12/14 11:04, Randy Dunlap wrote:
> > On 05/12/2014 08:54 AM, Daniel Vetter wrote:
> >> On Mon, May 12, 2014 at 08:23:45AM -0700, Randy Dunlap wrote:
> >>> On 05/12/2014 01:58 AM, Daniel Vetter wrote:
>  On Mon, May 12, 2014 at 06:24:57PM +1000, Dave Airlie wrote:
> >>> If we decide to go for property documentation inside the source code
> >>> then I believe we'll have to create our own format, as creating a
> >>> properties table from kerneldoc information extracted from comments
> >>> is probably not possible.
> >> 
> >> Can comeone pick up the ball here and figure out what needs to be
> >> done?
> >> 
> >> The reason why I want a central place for the documentation is to
> >> force people to collaborate outside their own sandbox when adding
> >> properties. Whether that's docbook or some text file I don't care so
> >> much at this point. The fact that it's a central place should mandate
> >> that the patches changing it will go through dri-devel and so
> >> everyone should se them, and when adding new properties it would make
> >> the patch author more likely to look around a bit before adding
> >> another slighty incompatible version of the same property. If someone
> >> has a better suggestion how to encforce this I'm all ears.
> >> 
> >> Of course this idea can still fail if our esteemed maintainer merges
> >> stuff without checking for violations of this policy. Dave, any
> >> thoughts on the subject?
> > 
> > Yeah I'm happy to block merging stuff, if we can spot new properties
> > when stuff is posted on dri-devel, so much the better,
> > 
> > most drivers still send everything via dri-devel anyways, its only
> > really Intel I have to worry about so far,
>  
>  I'll enforce that all prop stuff gets cc: dri-devel and that it has
>  updates for the prop docs.
>  
> > But we should definitely add it to the new driver review checklist as
> > well.
> > 
> > I'm also on the side of this patch is ugly and makes my eyes burn,
> > please please get a plan to use something else ASAP, I'm willing to
> > merge this but I'm tempted to give it a lifetime of a kernel or two
> > before I burn it.
>  
>  Ok, I'll try to move "make kerneldoc suck less" up the task list and
>  maybe find someone to do it for me internally ;-)
> >>> 
> >>> I certainly have no objections to making kerneldoc suck less.
> >>> There was already an attempt to use asciidoc (like git uses) for
> >>> kernel-doc (a few years ago, by Sam Ravnborg).  I support(ed) that
> >>> effort.
> >> 
> >> Hm, do you have pointers to those? My google-fu seems lacking ...
> > 
> > I googled for /kernel doc asciidoc ravnborg/ and found several hits for
> > them.
> >
> >> Ok, let's move this to the top and start discussions. The past few months
> >> I've written piles of kerneldoc comments for the DRM DocBook (all pulled
> >> in as kerneldoc, docbook .tmpl has just the chapter structure). DOC:
> >> sections are really useful to pull all the actual documentation out of
> >> the docbook xml into kerneldoc.
> >> 
> >> But I've also done piles of docs for intel-gpu-tools, which is using
> >> gtkdoc. And there are some clear deficiencies:
> >> 
> >> - No markdown for inline coments. Lack of lists and tables is hurting
> >>   especially badly. If we add this (and I don't care one iota whether
> >>   it's
> > 
> > Yes, I've tried to add lists to kernel-doc notation but have failed so
> > far.
> > 
> >>   markdown or asciidoc or something else as long as it's readable plain
> >>   text in comments) we should be able to move all the existing docbook
> >>   xml paragraphs/lists/tables into kerneldoc comments.
> >> 
> >> - Automatic cross-referencing of functions. If you place e.g. function()
> >>   or #struct anywhere in a documentation comment gtk-doc automatically
> >>   inserts a hyperlink to the relevant documentation page across the
> >>   entire project. Really powerful and makes overview sections much more
> >>   useful entry points for beginners since they can easily jump back
> >>   betweeen the high-level overview and low-level per-function
> >>   documentation.
> > 
> > That's a nice-to-have IMO, but a really nice one.
> > 
> >> - In a really perfect world it would help if kerneldoc could collect
> >>   structure member kerneldoc from per-member comments. Especially for
> >>   large structures with lots of comments this would bring the kerneldoc
> >>   and struct member much closer together.
> >> 
> >> So that's my wishlist.
> >> 
> >>> OTOH, I would only want to add another way to do kernel-doc if it can be
> >>> a full replacement for all of our docbook usage, i.e., it should provide
> >>> a way that we can eliminate docbook and stop using it completely.
> >> 
> >> Hm, I don't mind docbook at all, as long as all the real 

[Bug 81907] Unreal Engine "Effects Cave" Demo crashes with SIGBUS in __memcpy_sse2_unaligned

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

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

--- Comment #2 from Michel D?nzer  ---
(In reply to comment #1)
> Many demos work now. But the Cave Demo does not work, it hangs the GPU.

Hmm, that one works for me. Only the Elemental and Sci-Fi Hallway demos run
into shader compiler failures and corresponding GPU VM faults for me, no hangs
though.


> I'll leave this bug report open, because I have no idea if this bug will
> reappear once the hang is fixed.

Right, they're probably separate problems and need to be tracked separately.

-- 
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/20140801/ee34c4ce/attachment.html>

[Bug 79980] Random radeonsi crashes

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

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

Andy Furniss  changed:

   What|Removed |Added

 Attachment #103818|0   |1
is obsolete||

-- 
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/20140801/e32422e0/attachment-0001.html>

[Bug 81991] X page allocation errors referencing radeon_vm_get_bos

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

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

--- Comment #2 from Michel D?nzer  ---
(In reply to comment #1)
> This is a kernel out of memory error not a driver bug.  The driver is not
> able to allocate the memory it needs.

That may be technically true, but order 4 means 16 physically contiguous pages
IIUC, which may be difficult for the kernel to provide. We can avoid this by
making radeon_vm_get_bos() allocate each list node separately instead of a
single large array for all of them.

-- 
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/20140801/82cf47ec/attachment.html>

[Bug 79980] Random radeonsi crashes

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

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

--- Comment #83 from Andy Furniss  ---
(In reply to comment #82)
> (In reply to comment #80)
> > 
> > I have got the new firmware (unless there's an even newer one) and have
> > booted into the other 3.17 before - but it eventually crashed due to missing
> > fixes.
> 
> When did you download it?  The header format changed last week and I
> uploaded a new version.

Ahh, it was longer ago that that, will try newer.

-- 
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/20140801/f77a5afa/attachment.html>

[Bug 79980] Random radeonsi crashes

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

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

--- Comment #82 from Alex Deucher  ---
(In reply to comment #80)
> 
> I have got the new firmware (unless there's an even newer one) and have
> booted into the other 3.17 before - but it eventually crashed due to missing
> fixes.

When did you download it?  The header format changed last week and I uploaded a
new version.

-- 
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/20140801/d2446a21/attachment.html>

[Bug 79980] Random radeonsi crashes

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

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

--- Comment #81 from Michel D?nzer  ---
(In reply to comment #80)
> Well I just tried drm-next-3.17-rebased-on-fixes and it died as soon as
> fbcon loaded. Screen full junk and an oops logged.

Please file a new report for that, it's nothing to do with random crashes in X.

-- 
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/20140801/eaf1e550/attachment.html>

[Bug 79980] Random radeonsi crashes

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

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

--- Comment #80 from Andy Furniss  ---
(In reply to comment #78)
> just saw that there are new updates in
> 
> http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.17-wip &
> 
> http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.17-rebased-on-
> fixes
> 
> 
> 
> hopefully the changes make a difference, will try out the new
> drm-next-3.17-rebased-on-fixes in approximately a day or later
> 
> thanks guys !

Well I just tried drm-next-3.17-rebased-on-fixes and it died as soon as fbcon
loaded. Screen full junk and an oops logged.

I have got the new firmware (unless there's an even newer one) and have booted
into the other 3.17 before - but it eventually crashed due to missing fixes.

-- 
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/20140801/1e65927e/attachment.html>

[Bug 79980] Random radeonsi crashes

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

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

--- Comment #79 from Andy Furniss  ---
Created attachment 103818
  --> https://bugs.freedesktop.org/attachment.cgi?id=103818=edit
Oops on fbcon load drm-next-3.17-rebased-on-fixex

-- 
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/20140801/413f443e/attachment.html>

[PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support

[Andreas Färber]

Hi Ajay,

Am 01.08.2014 09:02, schrieb Ajay kumar:
> On Thu, Jul 31, 2014 at 7:52 PM, Andreas F?rber  wrote:
>> So, with simplefb reverted in U-Boot and ...
>>
>> * with just the v6 applied (...~2), I get only a black screen from
>> Linux, no penguins, but the backlight seems on. System comes up okay,
>> ssh available, and nothing stands out in dmesg.
>>
>> * with the two iommu patches on top, something breaks badly, no
>> backlight, no USB/network, system inaccessible.
>> I.e. U-Boot had no noticeable impact on these symptoms.
>>
>> * with the iommu patches, but dp-controller, ps8622, panel commented
>> out, I do get backlight but USB/network not working, system inaccessible.
>>
>> With simplefb support in U-Boot and with just v6 applied, but
>> dp-controller, ps8622, panel commented out, things work as well as
>> before, i.e. this series has no bad side effects. Note that I never
>> claimed Ajay's series were broken, just reported that things regressed
>> for me from v4, which may well be DT-related.
>>
>> The iommu patches interfere with my USB somehow (none or not all devices
>> powered; with v4, plugging my wifi dongle led to oops but ethernet
>> dongle worked, so not entirely new symptom), which is bad since my
>> rootfs is on USB. The internal SDIO-connected Wifi is not enabled yet,
>> so USB based network is my only alternative to a working display once we
>> reach userspace.
> Well, there are 2 variants here:
> 1) Bootloader
> 2) config
> 
> Type of the bootloader should not matter unless its switching on
> FET1 and FET6 of tps65090 for you.
> 
> But, config can be different!
> I have attached a config i used to get display with your latest
> spring-bridge.v6.
> Uncomment the DT nodes for DP and bridge chip and you should
> be able to get display and also the login.
> 
> I think that you have not selected all the configs needed for IOMMU to
> work properly. When I deselected few IOMMU configs, I could see system
> crashing when FIMD + DP path was being initialized. May be, that is why your
> USB stops working. Even I have root file system on USB drive.

Find attached a diff between our configs. The following stand out:

* I have LPAE enabled
* you don't have DMA enabled
* I have CMA enabled (like in the new defconfigs)
* I have the arch timer disabled (which you suggested earlier for delay)
* I have more devices enabled (SPI, PWM, cpufreq, watchdog, ...)

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg
-- next part --
A non-text attachment was scrubbed...
Name: config-ajay.diff
Type: text/x-patch
Size: 27283 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140801/cfcd4f80/attachment-0001.bin>

Re: [Radeon RV280] radeon_cs_gem.c:181: cs_gem_write_reloc: Assertion »boi->space_accounted« failed, core dumped

[Marek Olšák]

Does the attached libdrm patch fix the issue for you?

Marek

On Fri, Aug 1, 2014 at 1:16 PM, Marek Ol??k  wrote:
> Not in this case. You added a fail path to a function which isn't
> supposed to fail under these circumstances. No wonder Mesa couldn't
> cope with it. It really has nothing to do with your original issue.
>
> Marek
>
> On Fri, Aug 1, 2014 at 9:25 AM, Jochen Rollwagen  
> wrote:
>> I've built the latest libdrm and replaced the assertion in radeon_cs_gem.c.
>> with
>>
>> if (!boi->space_accounted) return -EINVAL;
>>
>> I now get the following crash in the cutscene:
>>
>>
>> CS section size missmatch start at (r200_state_init.c,ctx_emit_cs,487) 28 vs
>> 24
>> CS section end at (r200_state_init.c,ctx_emit_cs,520)
>> CS section size missmatch start at (r200_state_init.c,tex_emit_mm,572) 13 vs
>> 11
>> CS section end at (r200_state_init.c,tex_emit_mm,588)
>> drmRadeonCmdBuffer: -22. Kernel failed to parse or rejected command stream.
>> See dmesg for more info.
>>
>>
>> dmesg output is:
>>
>> [ 1232.744676] [drm:radeon_cs_packet_next_reloc] *ERROR* No packet3 for
>> relocati
>> on for packet at 34.
>> [ 1232.744691] [drm] ib[34]=0x0712
>> [ 1232.744694] [drm] ib[35]=0x00010340
>> [ 1232.744698] [drm:r200_packet0_check] *ERROR* No reloc for ib[33]=0x1C40
>> [ 1232.744701] [drm] ib[32]=0x0710
>> [ 1232.744704] [drm] ib[33]=0x
>> [ 1232.744707] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
>>
>> So it's really a mesa bug :-(
>>
>>
>>
>> Am 27.07.2014 um 14:47 schrieb Marek Ol??k:
>>>
>>> I think the problem is the driver hasn't called
>>>
>>> radeon_cs_space_add_persistent_bo.
>>>
>>> Marek
>>>
>>> On Fri, Jul 25, 2014 at 6:32 PM, Jochen Rollwagen 
>>> wrote:
>>>>
>>>> I've recently ported the peopsxgl OpenGL-GPU-Plugin for the pcsx
>>>> Playstation1 Emulator to the Powerpc-architecture. When running certain
>>>> games (for instance "Vagrant Stories") during longer cut-scenes i get a
>>>> reproducible crash of the radeon drm driver (i.e. it always crashes at
>>>> certain points in the scene) with the following message (in german):
>>>>
>>>> pcsx: radeon_cs_gem.c:181: cs_gem_write_reloc: Zusicherung
>>>> ?boi->space_accounted? nicht erf?llt.
>>>> Abgebrochen (Speicherabzug geschrieben)
>>>>
>>>> This happens with all the latest 3.10, 3.12 and 3.14 kernels.
>>>>
>>>> Other than that i'm running the latest xorg-ati driver, libdrm and mesa
>>>> from
>>>> git on a Mac Mini G4 (PowerPC).
>>>>
>>>> OpenGL vendor string: Mesa Project
>>>> OpenGL renderer string: Mesa DRI R200 (RV280 5962)  TCL DRI2
>>>> OpenGL version string: 1.3 Mesa 10.1.6 (git-42f86ef)
>>>>
>>>> I guess the issue is memory/vm/swap-related since the machine only has 1
>>>> gb
>>>> RAM. The GPU has 64 MB VRAM.
>>>>
>>>> Any ideas what i could do to avoid these crashes ?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ___
>>>> dri-devel mailing list
>>>> dri-devel at lists.freedesktop.org
>>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>>
-- next part --
A non-text attachment was scrubbed...
Name: 0001-radeon-allow-write_reloc-with-unaccounted-buffers-to.patch
Type: text/x-patch
Size: 952 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140801/e7e40346/attachment-0001.bin>

[Bug 81991] X page allocation errors referencing radeon_vm_get_bos

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

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

--- Comment #1 from Alex Deucher  ---
This is a kernel out of memory error not a driver bug.  The driver is not able
to allocate the memory it needs.

-- 
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/20140801/c9e226d0/attachment.html>

Re: [Radeon RV280] radeon_cs_gem.c:181: cs_gem_write_reloc: Assertion »boi->space_accounted« failed, core dumped

[Marek Olšák]

Not in this case. You added a fail path to a function which isn't
supposed to fail under these circumstances. No wonder Mesa couldn't
cope with it. It really has nothing to do with your original issue.

Marek

On Fri, Aug 1, 2014 at 9:25 AM, Jochen Rollwagen  
wrote:
> I've built the latest libdrm and replaced the assertion in radeon_cs_gem.c.
> with
>
> if (!boi->space_accounted) return -EINVAL;
>
> I now get the following crash in the cutscene:
>
>
> CS section size missmatch start at (r200_state_init.c,ctx_emit_cs,487) 28 vs
> 24
> CS section end at (r200_state_init.c,ctx_emit_cs,520)
> CS section size missmatch start at (r200_state_init.c,tex_emit_mm,572) 13 vs
> 11
> CS section end at (r200_state_init.c,tex_emit_mm,588)
> drmRadeonCmdBuffer: -22. Kernel failed to parse or rejected command stream.
> See dmesg for more info.
>
>
> dmesg output is:
>
> [ 1232.744676] [drm:radeon_cs_packet_next_reloc] *ERROR* No packet3 for
> relocati
> on for packet at 34.
> [ 1232.744691] [drm] ib[34]=0x0712
> [ 1232.744694] [drm] ib[35]=0x00010340
> [ 1232.744698] [drm:r200_packet0_check] *ERROR* No reloc for ib[33]=0x1C40
> [ 1232.744701] [drm] ib[32]=0x0710
> [ 1232.744704] [drm] ib[33]=0x
> [ 1232.744707] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
>
> So it's really a mesa bug :-(
>
>
>
> Am 27.07.2014 um 14:47 schrieb Marek Ol??k:
>>
>> I think the problem is the driver hasn't called
>>
>> radeon_cs_space_add_persistent_bo.
>>
>> Marek
>>
>> On Fri, Jul 25, 2014 at 6:32 PM, Jochen Rollwagen 
>> wrote:
>>>
>>> I've recently ported the peopsxgl OpenGL-GPU-Plugin for the pcsx
>>> Playstation1 Emulator to the Powerpc-architecture. When running certain
>>> games (for instance "Vagrant Stories") during longer cut-scenes i get a
>>> reproducible crash of the radeon drm driver (i.e. it always crashes at
>>> certain points in the scene) with the following message (in german):
>>>
>>> pcsx: radeon_cs_gem.c:181: cs_gem_write_reloc: Zusicherung
>>> ?boi->space_accounted? nicht erf?llt.
>>> Abgebrochen (Speicherabzug geschrieben)
>>>
>>> This happens with all the latest 3.10, 3.12 and 3.14 kernels.
>>>
>>> Other than that i'm running the latest xorg-ati driver, libdrm and mesa
>>> from
>>> git on a Mac Mini G4 (PowerPC).
>>>
>>> OpenGL vendor string: Mesa Project
>>> OpenGL renderer string: Mesa DRI R200 (RV280 5962)  TCL DRI2
>>> OpenGL version string: 1.3 Mesa 10.1.6 (git-42f86ef)
>>>
>>> I guess the issue is memory/vm/swap-related since the machine only has 1
>>> gb
>>> RAM. The GPU has 64 MB VRAM.
>>>
>>> Any ideas what i could do to avoid these crashes ?
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> dri-devel mailing list
>>> dri-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>

[PATCH 00/15] drm/panel: Add prepare and unprepare routines

[Thierry Reding]

On Thu, Jul 31, 2014 at 11:11:59PM +0530, Ajay Kumar wrote:
> This series is based on exynos-drm-next branch of Inki Dae's tree at:
> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
> 
> This is originally a part of the bridge chip series:
> http://www.spinics.net/lists/linux-samsung-soc/msg34826.html
> 
> But, since we can handle panel and bridge chips seperately,
> I thought of seperating them.
> 
> This patchset basically extends the drm panel framework
> to accomodate wider range of panels with strict timing
> sequence for enabling panel power, backlight enable, etc.
> 
> I have tested this patchset on exynos5800-peach-pi board.
> 
> Thierry:
>   As discussed, I have seperated patches such that they
>   won't break the compilation in between. Also, I have
>   incorporated all the comments given by you for panel patches.
>   I assume you have already taken [PATCH 01/15] and hence
>   it can be dropped from this patchset.
> 
> Ajay Kumar (15):
>   [PATCH 01/15] drm/panel: add prepare and unprepare routines
>   [PATCH 02/15] drm/panel: Add get_modes helper
>   [PATCH 03/15] drm/panel: ld9040: Add dummy prepare and unprepare routines
>   [PATCH 04/15] drm/panel: s6e8aa0: Add dummy prepare and unprepare routines
>   [PATCH 05/15] drm/panel: simple: Add dummy prepare and unprepare routines
>   [PATCH 06/15] drm/exynos: dpi: Add support for panel prepare and unprepare 
> routines
>   [PATCH 07/15] drm/exynos: dsi: Add support for panel prepare and unprepare 
> routines
>   [PATCH 08/15] drm/tegra: Add support for panel prepare and unprepare 
> routines
>   [PATCH 09/15] drm/panel: ld9040: Add proper definition for prepare and 
> unprepare
>   [PATCH 10/15] drm/panel: s6e8aa0: Add proper definition for prepare and 
> unprepare
>   [PATCH 11/15] drm/panel: simple: Add proper definition for prepare and 
> unprepare
>   [PATCH 12/15] drm/panel: simple: Support usage of delays in panel functions
>   [PATCH 13/15] drm/panel: simple: Add support for auo_b133htn01 panel
>   [PATCH 14/15] drm/exynos: Move DP setup into commit()
>   [PATCH 15/15] drm/exynos: dp: Modify driver to support drm_panel

I already had patches 01/15 and 02/15, but I've applied the rest of the
series. I went out on a limb and applied Inki's Acked-by to all Exynos-
related patches, assuming that was the intention.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140801/4e785e46/attachment.sig>

[Bug 78453] [HAWAII] Get acceleration working

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

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

--- Comment #139 from Marek Ol??k  ---
(In reply to comment #137)
> You might try the patches I posted on bug 74250.

Sorry, they don't help.

-- 
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/20140801/b6130b12/attachment.html>

[PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support

[Ajay kumar]

Andreas,

On Thu, Jul 31, 2014 at 7:52 PM, Andreas F?rber  wrote:
> Am 31.07.2014 12:23, schrieb Thierry Reding:
>> On Thu, Jul 31, 2014 at 10:57:55AM +0200, Andreas F?rber wrote:
>>> Am 31.07.2014 10:38, schrieb Ajay kumar:
 With just the spring-bridge.v6 branch of your own tree, I am able to see
 bootup logo on Skate(a variant of spring which also contains ps8622).
 I have tried both exynos_defconfig and multi_v7_defconfig.
 I enable DRM, EXYNOS DRM, BRIDGE CHIPS, IOMMU, EXYNOS IOMMU
 in configs.
> [...]
>> If you have something like simplefb enabled in addition to a DRM driver,
>> then perhaps the DRM driver isn't properly taking over the framebuffer
>> console.
>
> So, with simplefb reverted in U-Boot and ...
>
> * with just the v6 applied (...~2), I get only a black screen from
> Linux, no penguins, but the backlight seems on. System comes up okay,
> ssh available, and nothing stands out in dmesg.
>
> * with the two iommu patches on top, something breaks badly, no
> backlight, no USB/network, system inaccessible.
> I.e. U-Boot had no noticeable impact on these symptoms.
>
> * with the iommu patches, but dp-controller, ps8622, panel commented
> out, I do get backlight but USB/network not working, system inaccessible.
>
> With simplefb support in U-Boot and with just v6 applied, but
> dp-controller, ps8622, panel commented out, things work as well as
> before, i.e. this series has no bad side effects. Note that I never
> claimed Ajay's series were broken, just reported that things regressed
> for me from v4, which may well be DT-related.
>
> The iommu patches interfere with my USB somehow (none or not all devices
> powered; with v4, plugging my wifi dongle led to oops but ethernet
> dongle worked, so not entirely new symptom), which is bad since my
> rootfs is on USB. The internal SDIO-connected Wifi is not enabled yet,
> so USB based network is my only alternative to a working display once we
> reach userspace.
Well, there are 2 variants here:
1) Bootloader
2) config

Type of the bootloader should not matter unless its switching on
FET1 and FET6 of tps65090 for you.

But, config can be different!
I have attached a config i used to get display with your latest
spring-bridge.v6.
Uncomment the DT nodes for DP and bridge chip and you should
be able to get display and also the login.

I think that you have not selected all the configs needed for IOMMU to
work properly. When I deselected few IOMMU configs, I could see system
crashing when FIMD + DP path was being initialized. May be, that is why your
USB stops working. Even I have root file system on USB drive.


Just give a try with this config and let me know your observation.
If you still observe the same behavior, may be I need to flash new
bootloader onto  my board and try. :(

Ajay
-- next part --
#
# Automatically generated file; DO NOT EDIT.
# Linux/arm 3.16.0-rc6 Kernel Configuration
#
CONFIG_ARM=y
CONFIG_ARM_HAS_SG_CHAIN=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_ARM_DMA_USE_IOMMU=y
CONFIG_ARM_DMA_IOMMU_ALIGNMENT=8
CONFIG_MIGHT_HAVE_PCI=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_HAVE_PROC_CPU=y
CONFIG_NO_IOPORT_MAP=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_BANDGAP=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_VECTORS_BASE=0x
CONFIG_ARM_PATCH_PHYS_VIRT=y
CONFIG_GENERIC_BUG=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
CONFIG_CROSS_MEMORY_ATTACH=y
# CONFIG_FHANDLE is not set
CONFIG_USELIB=y
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_KTIME_SCALAR=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_ARCH_HAS_TICK_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
# CONFIG_NO_HZ_FULL is not set
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
# CONFIG_IRQ_TIME_ACCOUNTING is 

[PATCH 06/15] drm/exynos: dpi: Add support for panel prepare and unprepare routines

[Thierry Reding]

On Fri, Aug 01, 2014 at 06:24:42PM +0900, Inki Dae wrote:
> On 2014? 08? 01? 18:04, Thierry Reding wrote:
> > On Thu, Jul 31, 2014 at 11:12:05PM +0530, Ajay Kumar wrote:
> >> Modify exynos_dpi driver to support the new panel calls:
> >> prepare and unprepare.
> >>
> >> Signed-off-by: Ajay Kumar 
> >> ---
> >>  drivers/gpu/drm/exynos/exynos_drm_dpi.c |8 ++--
> >>  1 file changed, 6 insertions(+), 2 deletions(-)
> > 
> > Looks good to me. Inki, can I have your Acked-by to take this through
> > the panel tree?
> 
> Of course.
> 
> Acked-by: Inki Dae 

I'll take it that this Acked-by applies also to patch 07/15?

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140801/d8ecb8ce/attachment.sig>

[PATCH 14/15] drm/exynos: Move DP setup into commit()

[Thierry Reding]

On Fri, Aug 01, 2014 at 03:11:37PM +0530, Ajay kumar wrote:
> On Fri, Aug 1, 2014 at 2:48 PM, Thierry Reding  
> wrote:
> > On Thu, Jul 31, 2014 at 11:12:13PM +0530, Ajay Kumar wrote:
> >> Add commit callback for exynos_dp, and move the DP link training,
> >> video configuration code from the hotplug handler into commit().
> >>
> >> Signed-off-by: Sean Paul 
> >> Signed-off-by: Ajay Kumar 
> >> ---
> >>  drivers/gpu/drm/exynos/exynos_dp_core.c |   24 +++-
> >>  1 file changed, 19 insertions(+), 5 deletions(-)
> >
> > This is not related to the other patches in the series, so it can be
> > applied independently.
> This patch should go in this series only.
> [PATCH 15/15] has dependency on this because it modifies exynos_dp_commit().

Okay, I'll apply it to the panel tree. Inki, can I assume your Acked-by
from patch 06/15 applies to this one as well?

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140801/f00ba7d5/attachment.sig>

[PATCH 17/19] drm/radeon: use rcu waits in some ioctls

[Maarten Lankhorst]

Hey,

On 01-08-14 10:27, Michel D?nzer wrote:
> On 01.08.2014 00:34, Maarten Lankhorst wrote:
>>
>> @@ -357,14 +360,20 @@ int radeon_gem_wait_idle_ioctl(struct drm_device *dev, 
>> void *data,
>>  struct drm_radeon_gem_wait_idle *args = data;
>>  struct drm_gem_object *gobj;
>>  struct radeon_bo *robj;
>> -int r;
>> +int r = 0;
>> +long ret;
>>  
>>  gobj = drm_gem_object_lookup(dev, filp, args->handle);
>>  if (gobj == NULL) {
>>  return -ENOENT;
>>  }
>>  robj = gem_to_radeon_bo(gobj);
>> -r = radeon_bo_wait(robj, NULL, false);
>> +ret = reservation_object_wait_timeout_rcu(robj->tbo.resv, true, true, 
>> 30 * HZ);
>> +if (ret == 0)
>> +r = -EBUSY;
>> +else if (ret < 0)
>> +r = ret;
>> +
>>  /* callback hw specific functions if any */
>>  if (rdev->asic->ioctl_wait_idle)
>>  robj->rdev->asic->ioctl_wait_idle(rdev, robj);
> 
> Heads up, this conflicts with
> http://lists.freedesktop.org/archives/dri-devel/2014-August/065255.html
> which passes a non-NULL second argument to radeon_bo_wait() to get the
> BO's current domain.
Ok, I will fix it up and resend it later.

Does it matter if I grab the current domain without grabbing the lock here? 
Because it doesn't matter if it sees the old or new domain, it could have been 
changed after returning too.

~Maarten

[PATCH V2] drm/tegra: add MODULE_DEVICE_TABLEs

[Thierry Reding]

On Wed, Jul 23, 2014 at 01:29:32PM -0600, Stephen Warren wrote:
> On 06/18/2014 04:21 PM, Stephen Warren wrote:
> > From: Stephen Warren 
> > 
> > When tegra-drm.ko is built as a module, these MODULE_DEVICE_TABLEs allow
> > the module to be auto-loaded since the module will match the devices
> > instantiated from device tree.
> > 
> > (Notes for stable: in 3.14+, just git rm any conflicting file, since they
> > are added in later kernels. For 3.13 and below, manual merging will be
> > needed)
> > 
> > Cc: 
> > Signed-off-by: Stephen Warren 
> > ---
> > v2: Remove change to drm.c, since the match table there isn't used for
> > probing.
> 
> Thierry, I think this patch got lost? It doesn't appear in next-20140721
> anyway.

Applied, sorry for the delay.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140801/0b8acfed/attachment.sig>

[PATCH 14/15] drm/exynos: Move DP setup into commit()

[Thierry Reding]

On Thu, Jul 31, 2014 at 11:12:13PM +0530, Ajay Kumar wrote:
> Add commit callback for exynos_dp, and move the DP link training,
> video configuration code from the hotplug handler into commit().
> 
> Signed-off-by: Sean Paul 
> Signed-off-by: Ajay Kumar 
> ---
>  drivers/gpu/drm/exynos/exynos_dp_core.c |   24 +++-
>  1 file changed, 19 insertions(+), 5 deletions(-)

This is not related to the other patches in the series, so it can be
applied independently.

Sean, this looks like a back-/forward-port of the patch you linked to in
reply to an earlier version of the series, does this still correspond to
what you think it should be doing? (hence not trimming the quote)

Thierry

> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> index 31c3de9..347dec9 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
> @@ -875,10 +875,18 @@ static irqreturn_t exynos_dp_irq_handler(int irq, void 
> *arg)
>  static void exynos_dp_hotplug(struct work_struct *work)
>  {
>   struct exynos_dp_device *dp;
> - int ret;
>  
>   dp = container_of(work, struct exynos_dp_device, hotplug_work);
>  
> + if (dp->drm_dev)
> + drm_helper_hpd_irq_event(dp->drm_dev);
> +}
> +
> +static void exynos_dp_commit(struct exynos_drm_display *display)
> +{
> + struct exynos_dp_device *dp = display->ctx;
> + int ret;
> +
>   ret = exynos_dp_detect_hpd(dp);
>   if (ret) {
>   /* Cable has been disconnected, we're done */
> @@ -1050,8 +1058,10 @@ static void exynos_dp_phy_exit(struct exynos_dp_device 
> *dp)
>   }
>  }
>  
> -static void exynos_dp_poweron(struct exynos_dp_device *dp)
> +static void exynos_dp_poweron(struct exynos_drm_display *display)
>  {
> + struct exynos_dp_device *dp = display->ctx;
> +
>   if (dp->dpms_mode == DRM_MODE_DPMS_ON)
>   return;
>  
> @@ -1059,10 +1069,13 @@ static void exynos_dp_poweron(struct exynos_dp_device 
> *dp)
>   exynos_dp_phy_init(dp);
>   exynos_dp_init_dp(dp);
>   enable_irq(dp->irq);
> + exynos_dp_commit(display);
>  }
>  
> -static void exynos_dp_poweroff(struct exynos_dp_device *dp)
> +static void exynos_dp_poweroff(struct exynos_drm_display *display)
>  {
> + struct exynos_dp_device *dp = display->ctx;
> +
>   if (dp->dpms_mode != DRM_MODE_DPMS_ON)
>   return;
>  
> @@ -1078,12 +1091,12 @@ static void exynos_dp_dpms(struct exynos_drm_display 
> *display, int mode)
>  
>   switch (mode) {
>   case DRM_MODE_DPMS_ON:
> - exynos_dp_poweron(dp);
> + exynos_dp_poweron(display);
>   break;
>   case DRM_MODE_DPMS_STANDBY:
>   case DRM_MODE_DPMS_SUSPEND:
>   case DRM_MODE_DPMS_OFF:
> - exynos_dp_poweroff(dp);
> + exynos_dp_poweroff(display);
>   break;
>   default:
>   break;
> @@ -1094,6 +1107,7 @@ static void exynos_dp_dpms(struct exynos_drm_display 
> *display, int mode)
>  static struct exynos_drm_display_ops exynos_dp_display_ops = {
>   .create_connector = exynos_dp_create_connector,
>   .dpms = exynos_dp_dpms,
> + .commit = exynos_dp_commit,
>  };
>  
>  static struct exynos_drm_display exynos_dp_display = {
> -- 
> 1.7.9.5
> 
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140801/9c6d98ce/attachment.sig>

[PATCH 15/15] drm/exynos: dp: Modify driver to support drm_panel

[Thierry Reding]

On Thu, Jul 31, 2014 at 11:12:14PM +0530, Ajay Kumar wrote:
> Add drm_panel controls to support powerup/down of the
> eDP panel, if one is present at the sink side.
> 
> Signed-off-by: Ajay Kumar 
> ---
>  drivers/gpu/drm/exynos/Kconfig  |1 +
>  drivers/gpu/drm/exynos/exynos_dp_core.c |   88 
> ---
>  drivers/gpu/drm/exynos/exynos_dp_core.h |3 +-
>  3 files changed, 71 insertions(+), 21 deletions(-)

Inki, I'll need an Acked-by from you on this one as well. It has a build
time dependency on earlier patches in this series, so taking it through
the panel tree along with the rest is probably easiest.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140801/59050a65/attachment-0001.sig>

[PATCH 07/15] drm/exynos: dsi: Add support for panel prepare and unprepare routines

[Thierry Reding]

On Thu, Jul 31, 2014 at 11:12:06PM +0530, Ajay Kumar wrote:
> Modify exynos_dsi driver to support the new panel calls:
> prepare and unprepare.
> 
> Signed-off-by: Ajay Kumar 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c |   12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)

And this one as well.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140801/f004fc2b/attachment.sig>

[PATCH 06/15] drm/exynos: dpi: Add support for panel prepare and unprepare routines

[Thierry Reding]

On Thu, Jul 31, 2014 at 11:12:05PM +0530, Ajay Kumar wrote:
> Modify exynos_dpi driver to support the new panel calls:
> prepare and unprepare.
> 
> Signed-off-by: Ajay Kumar 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_dpi.c |8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)

Looks good to me. Inki, can I have your Acked-by to take this through
the panel tree?

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140801/3a0e4615/attachment.sig>

[PATCH] drm/radeon: Only flush HDP cache from idle ioctl if BO is in VRAM

[Christian König]

Am 01.08.2014 um 10:22 schrieb Michel D?nzer:
> From: Michel D?nzer 
>
> The HDP cache only applies to CPU access to VRAM.
>
> Signed-off-by: Michel D?nzer 

Wanted to suggest the same thing already, looks like a valid 
optimization to me.

Patch is Reviewed-by: Christian K?nig 

> ---
>   drivers/gpu/drm/radeon/radeon_gem.c | 6 --
>   1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_gem.c 
> b/drivers/gpu/drm/radeon/radeon_gem.c
> index a350cf9..8f2cb58 100644
> --- a/drivers/gpu/drm/radeon/radeon_gem.c
> +++ b/drivers/gpu/drm/radeon/radeon_gem.c
> @@ -359,15 +359,17 @@ int radeon_gem_wait_idle_ioctl(struct drm_device *dev, 
> void *data,
>   struct drm_gem_object *gobj;
>   struct radeon_bo *robj;
>   int r;
> + uint32_t cur_placement = 0;
>   
>   gobj = drm_gem_object_lookup(dev, filp, args->handle);
>   if (gobj == NULL) {
>   return -ENOENT;
>   }
>   robj = gem_to_radeon_bo(gobj);
> - r = radeon_bo_wait(robj, NULL, false);
> + r = radeon_bo_wait(robj, _placement, false);
>   /* Flush HDP cache via MMIO if necessary */
> - if (rdev->asic->mmio_hdp_flush)
> + if (rdev->asic->mmio_hdp_flush &&
> + radeon_mem_type_to_domain(cur_placement) == RADEON_GEM_DOMAIN_VRAM)
>   robj->rdev->asic->mmio_hdp_flush(rdev);
>   drm_gem_object_unreference_unlocked(gobj);
>   r = radeon_gem_handle_lockup(rdev, r);

[Bug 81907] Unreal Engine "Effects Cave" Demo crashes with SIGBUS in __memcpy_sse2_unaligned

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

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

--- Comment #1 from Christoph Haag  ---
Some information in case someone tries to reproduce it.

I applied this patch additionally to the revert:
https://bugs.freedesktop.org/show_bug.cgi?id=80880#c10

Many demos work now. But the Cave Demo does not work, it hangs the GPU.

I can not reproduce the original bug I posted here anymore with the patch, just
the hang. It looks like this:

ring 0 stalled for more than 10146msec
GPU lockup (waiting for 0xa921 last fence id 0xa920 on
ring 0)
failed to get a new IB (-35)
Saved 205 dwords of commands on ring 0.
GPU softreset: 0x004D
  GRBM_STATUS   = 0xE7DE5028
  GRBM_STATUS_SE0   = 0xEF82
  GRBM_STATUS_SE1   = 0xEFC2
  SRBM_STATUS   = 0x20C0
  SRBM_STATUS2  = 0x
  R_008674_CP_STALLED_STAT1 = 0x
  R_008678_CP_STALLED_STAT2 = 0x00010800
  R_00867C_CP_BUSY_STAT = 0x00408006
  R_008680_CP_STAT  = 0x84038647
  R_00D034_DMA_STATUS_REG   = 0x44C83146
  R_00D834_DMA_STATUS_REG   = 0x44C83D57
  VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x
  VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x
GRBM_SOFT_RESET=0xDDFF
SRBM_SOFT_RESET=0x00100100
  GRBM_STATUS   = 0x3028
  GRBM_STATUS_SE0   = 0x0006
  GRBM_STATUS_SE1   = 0x0006
  SRBM_STATUS   = 0x20C0
  SRBM_STATUS2  = 0x
  R_008674_CP_STALLED_STAT1 = 0x
  R_008678_CP_STALLED_STAT2 = 0x
  R_00867C_CP_BUSY_STAT = 0x
  R_008680_CP_STAT  = 0x
  R_00D034_DMA_STATUS_REG   = 0x44C83D57
  R_00D834_DMA_STATUS_REG   = 0x44C83D57
GPU reset succeeded, trying to resume


I'll leave this bug report open, because I have no idea if this bug will
reappear once the hang is fixed.

-- 
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/20140801/262f2832/attachment.html>

[PATCH] drm/radeon: Only flush HDP cache from idle ioctl if BO is in VRAM

[Alex Deucher]

On Fri, Aug 1, 2014 at 4:22 AM, Michel D?nzer  wrote:
> From: Michel D?nzer 
>
> The HDP cache only applies to CPU access to VRAM.
>
> Signed-off-by: Michel D?nzer 

Applied to my 3.17 branch.

Thanks!

> ---
>  drivers/gpu/drm/radeon/radeon_gem.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_gem.c 
> b/drivers/gpu/drm/radeon/radeon_gem.c
> index a350cf9..8f2cb58 100644
> --- a/drivers/gpu/drm/radeon/radeon_gem.c
> +++ b/drivers/gpu/drm/radeon/radeon_gem.c
> @@ -359,15 +359,17 @@ int radeon_gem_wait_idle_ioctl(struct drm_device *dev, 
> void *data,
> struct drm_gem_object *gobj;
> struct radeon_bo *robj;
> int r;
> +   uint32_t cur_placement = 0;
>
> gobj = drm_gem_object_lookup(dev, filp, args->handle);
> if (gobj == NULL) {
> return -ENOENT;
> }
> robj = gem_to_radeon_bo(gobj);
> -   r = radeon_bo_wait(robj, NULL, false);
> +   r = radeon_bo_wait(robj, _placement, false);
> /* Flush HDP cache via MMIO if necessary */
> -   if (rdev->asic->mmio_hdp_flush)
> +   if (rdev->asic->mmio_hdp_flush &&
> +   radeon_mem_type_to_domain(cur_placement) == 
> RADEON_GEM_DOMAIN_VRAM)
> robj->rdev->asic->mmio_hdp_flush(rdev);
> drm_gem_object_unreference_unlocked(gobj);
> r = radeon_gem_handle_lockup(rdev, r);
> --
> 2.0.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Radeon RV280] radeon_cs_gem.c:181: cs_gem_write_reloc: Assertion »boi->space_accounted« failed, core dumped

[Jochen Rollwagen]

I've built the latest libdrm and replaced the assertion in 
radeon_cs_gem.c. with

if (!boi->space_accounted) return -EINVAL;

I now get the following crash in the cutscene:


CS section size missmatch start at (r200_state_init.c,ctx_emit_cs,487) 
28 vs 24
CS section end at (r200_state_init.c,ctx_emit_cs,520)
CS section size missmatch start at (r200_state_init.c,tex_emit_mm,572) 
13 vs 11
CS section end at (r200_state_init.c,tex_emit_mm,588)
drmRadeonCmdBuffer: -22. Kernel failed to parse or rejected command 
stream. See dmesg for more info.


dmesg output is:

[ 1232.744676] [drm:radeon_cs_packet_next_reloc] *ERROR* No packet3 for 
relocati
on for packet at 34.
[ 1232.744691] [drm] ib[34]=0x0712
[ 1232.744694] [drm] ib[35]=0x00010340
[ 1232.744698] [drm:r200_packet0_check] *ERROR* No reloc for ib[33]=0x1C40
[ 1232.744701] [drm] ib[32]=0x0710
[ 1232.744704] [drm] ib[33]=0x
[ 1232.744707] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !

So it's really a mesa bug :-(


Am 27.07.2014 um 14:47 schrieb Marek Ol??k:
> I think the problem is the driver hasn't called
> radeon_cs_space_add_persistent_bo.
>
> Marek
>
> On Fri, Jul 25, 2014 at 6:32 PM, Jochen Rollwagen  
> wrote:
>> I've recently ported the peopsxgl OpenGL-GPU-Plugin for the pcsx
>> Playstation1 Emulator to the Powerpc-architecture. When running certain
>> games (for instance "Vagrant Stories") during longer cut-scenes i get a
>> reproducible crash of the radeon drm driver (i.e. it always crashes at
>> certain points in the scene) with the following message (in german):
>>
>> pcsx: radeon_cs_gem.c:181: cs_gem_write_reloc: Zusicherung
>> ?boi->space_accounted? nicht erf?llt.
>> Abgebrochen (Speicherabzug geschrieben)
>>
>> This happens with all the latest 3.10, 3.12 and 3.14 kernels.
>>
>> Other than that i'm running the latest xorg-ati driver, libdrm and mesa from
>> git on a Mac Mini G4 (PowerPC).
>>
>> OpenGL vendor string: Mesa Project
>> OpenGL renderer string: Mesa DRI R200 (RV280 5962)  TCL DRI2
>> OpenGL version string: 1.3 Mesa 10.1.6 (git-42f86ef)
>>
>> I guess the issue is memory/vm/swap-related since the machine only has 1 gb
>> RAM. The GPU has 64 MB VRAM.
>>
>> Any ideas what i could do to avoid these crashes ?
>>
>>
>>
>>
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 81444] [drm:radeon_uvd_free_handles] *ERROR* Error destroying UVD (-22)!

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

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

Harald Judt  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #5 from Harald Judt  ---
Yes, there must be something else wrong (I guess in kernel) because VDPAU stops
working when the error has occurred. I'll try to find a scenario which is easy
to reproduce.

-- 
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/20140801/c8c981a9/attachment.html>

[Bug 81444] [drm:radeon_uvd_free_handles] *ERROR* Error destroying UVD (-22)!

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

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

--- Comment #4 from Christian K?nig  ---
Well, radeon_uvd_free_handles is only called if an application crashed or
didn't cleaned up the VDPAU driver correctly. (e.g. the kernel needs to
manually tell the hardware that a decoder isn't needed any more because the
application failed to do so).

So it's definately some kind of userspace problem involved here.

But neverless there is also something wrong with the kernel function, otherwise
you won't get -22 (-EINVAL) in your 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/20140801/d0f22efd/attachment.html>

[PATCH 16/19] drm/atomic-helpers: document how to implement async commit

[Rob Clark]

On Sun, Jul 27, 2014 at 5:41 PM, Daniel Vetter  
wrote:
> No helper function to do it all yet provided since no driver has
> support for driver core fences yet. Which we'd need to make the
> implementation really generic.
>
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 37 
> +
>  1 file changed, 37 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 9f7c45b91fe2..423f6bcec362 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -716,6 +716,43 @@ int drm_atomic_helper_commit(struct drm_device *dev,
>  EXPORT_SYMBOL(drm_atomic_helper_commit);
>
>  /**
> + * DOC: Implementing async commit
> + *
> + * For now the atomic helpers don't support async commit directly. If there 
> is
> + * real need it could be added though, using the dma-buf fence infrastructure
> + * for generic synchronization with outstanding rendering.
> + *
> + * For now drivers have to implement async commit themselves, with the 
> following
> + * sequence being the recommened one:
> + *
> + * 1. Run drm_atomic_helper_prepare_planes() first. This is the only function
> + * which commit needs to call which can fail, so we want to run it first and
> + * synchronously.

Without some converted driver to look at for reference, I wasn't
completely sure whether prepare_fb/cleanup_fb was intended to do some
refcnt'ing, etc.   Or just driver internal pin/unpin?

> + * 2. Synchronize with any outstanding async commit worker threads which 
> might
> + * affect the new state update. This can be done by either cancelling or
> + * flushing the work items, depending upon whether the driver can deal with
> + * cancelled updates. Note that it is important to ensure that the 
> framebuffer
> + * cleanup is still done when cancelling.

maybe just an issue of wording..  but if an async update was writing
the state object, then we'd need to block earlier than commit.  I
don't think that is what you meant, because the state object data
structure synchronization you have relies on read-only access from the
async commit.  Which would make me expect it would be sufficient to
move the synchronization part into the async commit worker (ie. it
would only need to sync w/ other workers, ie if you had multiple
work-queues)?


> + *
> + * For sufficient parallelism it is recommended to have a work item per crtc
> + * (for updates which don't touch global state) and a global one. Then we 
> only
> + * need to synchronize with the crtc work items for changed crtcs and the 
> global
> + * work item, which allows nice concurrent updates on disjoint sets of crtcs.

s/work item/work queue/?

> + * 3. The software state is updated synchronously with
> + * drm_atomic_helper_swap_state. Doing this under the protection of all 
> modeset
> + * locks means concurrent callers never see inconsistent state. And doing 
> this
> + * while it's guranateed that no relevant async worker runs means that async
> + * workers do not need grab any locks. Actually they must not grab locks, for
> + * otherwise the work flushing will deadlock.
> + *
> + * 4. Schedule a work item to do all subsequent steps, using the split-out
> + * commit helpers: a) pre-plane commit b) plane commit c) post-plane commit 
> and
> + * then cleaning up the framebuffers after one vblank has passed.

the *old* framebuffers..

I assume the atomic helpers don't really care how the driver does it,
as long as it does.  Somehow or another the driver would want to
schedule cleanup on the vblank of the *old* crtc, I guess.

BR,
-R


> + */
> +
> +/**
>   * drm_atomic_helper_prepare_planes - prepare plane resources after commit
>   * @dev: DRM device
>   * @state: atomic state object with old state structures
> --
> 2.0.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 81444] [drm:radeon_uvd_free_handles] *ERROR* Error destroying UVD (-22)!

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

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

--- Comment #3 from Harald Judt  ---
I believe the playback issues may not be related to the -22 error. I've
downgraded ffmpeg from 2.3 to 2.2.5, and the choppiness and issues both with xv
and vdpau seem solved, so this was very likely a software problem (long-time
test still pending).

I will try to reproduce the -22 error in one or two weeks, using kdenlive with
mlt (with vdpau support) seemed to have been a certain way to make it happen
pretty fast.

-- 
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/20140801/22f3294d/attachment.html>

[Bug 81991] New: X page allocation errors referencing radeon_vm_get_bos

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

hci   23419  0 
r8169  55423  0 
firewire_ohci  30581  0 
libahci20828  1 ahci
firewire_core  49708  1 firewire_ohci
snd43711  21
snd_usb_audio,snd_ctxfi,snd_hwdep,snd_timer,snd_pcm,snd_rawmidi,snd_usbmidi_lib,snd_seq_device
serio_raw   4289  0 
i2c_piix4   8488  0 
i2c_core   20478  7
drm,i2c_dev,i2c_piix4,drm_kms_helper,i2c_algo_bit,radeon,videodev
soundcore864  1 snd
mii 3819  1 r8169
pata_jmicron2443  0 
crc_itu_t   1283  1 firewire_core
hwmon   2834  3 asus_atk0110,k10temp,radeon
acpi_cpufreq6471  1 
wmi 8011  0 
loop   18568  0

-- 
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/20140801/b6b4d109/attachment-0001.html>

[Bug 81644] Random crashes on RadeonSI with Chromium.

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

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

--- Comment #24 from Aaron B  ---
Created attachment 103786
  --> https://bugs.freedesktop.org/attachment.cgi?id=103786=edit
DMesg of multile flash crashes.

I don't think it'll help much, it's more of the same from a dmesg, but this
crash was like the other I experienced, pooped me out to a command prompt after
some time. It stalled on some new rings other than 0, which is "nice" I guess.

But this was caused by Chromium, just refreshing a page or switching tabs, one
of those. When it happened, Counter Strike Source was murdered, so it affected
it too in some way. But, my steam log shows nothing with the output directed to
it. I guess it shut down too quick to flush anything to it. I don't really know
what else to do, I've been reading up the posts from Agd5f (Drazner?) posts and
I mean, I'm a programmer and do lots of assembly and it makes sense. I just
don't know where to start debugging such a lower level kernel problem. I
believe it's out of my realm too much so to try anything else besides post
logs. :/

-- 
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/20140801/f13e988c/attachment.html>

[Bug 79980] Random radeonsi crashes

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

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

--- Comment #78 from jackdachef at gmail.com ---
just saw that there are new updates in

http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.17-wip &

http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.17-rebased-on-fixes



hopefully the changes make a difference, will try out the new
drm-next-3.17-rebased-on-fixes in approximately a day or later

thanks guys !

-- 
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/20140801/f03175bc/attachment.html>

[Bug 81644] Random crashes on RadeonSI with Chromium.

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

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

--- Comment #23 from jackdachef at gmail.com ---
@Aaron:

try reading into Magic SYSRQ key: http://en.wikipedia.org/wiki/Magic_SysRq_key



next time when X seems to freeze - first do a Magic SYSRQ + R, then try to
imitate a "secure attention key" 
== Magic SYSRQ + k

whether that unlocks it


or if X doesn't show any change anymore but the system still seems to be alive:

Magic SYSRQ Key + r

then Magic SYSRQ Key + w
(what tasks or kernel threads, etc. is stuck)

then the rest of "REISUB" (Magic SYSRQ Key + e, i, s, u, b)


after the next start you can look through the contents of the kernel messages
in

/var/log/kern.log

via


tail -n 3500 /var/log/kern.log | less

(keyboard cursor up & down, quit via "q")


if the messages are too much 

try via


tail -n 7500 /var/log/kern.log | less

or higher


sudo may be needed, if not using root privileges

logging may be disabled, so it first might have to be enabled 


hope this helps ...

-- 
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/20140801/800eeaa7/attachment.html>

[Bug 79980] Random radeonsi crashes

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

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

--- Comment #77 from jackdachef at gmail.com ---
Created attachment 103777
  --> https://bugs.freedesktop.org/attachment.cgi?id=103777=edit
output of Xorg.0.log during uvd-test with DVD watching in fluxbox via smplayer

mark the "extra" explicitely set settings:

[   253.915] (**) RADEON(0): Option "EnablePageFlip" "off"
[   253.915] (**) RADEON(0): Option "ColorTiling" "on"
[   253.915] (**) RADEON(0): Option "AccelMethod" "Glamor"
[   253.915] (**) RADEON(0): Option "EXAVSync" "off"
[   253.915] (**) RADEON(0): Option "EXAPixmaps" "on"
[   253.915] (**) RADEON(0): Option "SwapbuffersWait" "on"

I read about commits from 3.14 to 3.16-rc* that mentioned pageflipping changes
but disabling that didn't make a change




*before* watching the DVD

I did another test

and accidentally watched a short portion of a HTML video on youtube with
chromium (actually only had intended to read lkml, but there was a reference
link and didn't mention that it was a video /facepalm), did some browsing, had
gnote running (and some more which I currently don't remember)

adobe flash was explicitely turned *off* via about:plugins

and X hardlocked while playing music (and mp3, via audacious) & browsing via
chromium


so at least in my case more and more signs seem to lead towards bug 81644
(https://bugs.freedesktop.org/show_bug.cgi?id=81644) and that chromium + html
video; or chromium and all sorts of video (vdpau doesn't apply here ?!)
triggers instability & (hard)locks

-- 
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/20140801/a4b6c179/attachment.html>

[Bug 79980] Random radeonsi crashes

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

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

--- Comment #76 from jackdachef at gmail.com ---
Created attachment 103776
  --> https://bugs.freedesktop.org/attachment.cgi?id=103776=edit
DVD watching (150 minutes) on fluxbox with only konsole & smplayer with vdpau
running

so obviously vdpau is *NOT* the problem here the whole movie played fine and
the whole box didn't lockup without any suspicious messages, data or behavior
on 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/20140801/23e72ed4/attachment.html>

[PATCH 15/15] drm/exynos: dp: Modify driver to support drm_panel

[Ajay Kumar]

Add drm_panel controls to support powerup/down of the
eDP panel, if one is present at the sink side.

Signed-off-by: Ajay Kumar 
---
 drivers/gpu/drm/exynos/Kconfig  |1 +
 drivers/gpu/drm/exynos/exynos_dp_core.c |   88 ---
 drivers/gpu/drm/exynos/exynos_dp_core.h |3 +-
 3 files changed, 71 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 9ba1aae..7f9f6f9 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -53,6 +53,7 @@ config DRM_EXYNOS_DP
bool "EXYNOS DRM DP driver support"
depends on DRM_EXYNOS_FIMD && ARCH_EXYNOS && (DRM_PTN3460=n || 
DRM_PTN3460=y || DRM_PTN3460=DRM_EXYNOS)
default DRM_EXYNOS
+   select DRM_PANEL
help
  This enables support for DP device.

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 347dec9..4f3c7eb 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -16,7 +16,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -28,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 

 #include "exynos_drm_drv.h"
@@ -41,7 +41,7 @@ struct bridge_init {
struct device_node *node;
 };

-static int exynos_dp_init_dp(struct exynos_dp_device *dp)
+static void exynos_dp_init_dp(struct exynos_dp_device *dp)
 {
exynos_dp_reset(dp);

@@ -58,8 +58,6 @@ static int exynos_dp_init_dp(struct exynos_dp_device *dp)

exynos_dp_init_hpd(dp);
exynos_dp_init_aux(dp);
-
-   return 0;
 }

 static int exynos_dp_detect_hpd(struct exynos_dp_device *dp)
@@ -887,6 +885,12 @@ static void exynos_dp_commit(struct exynos_drm_display 
*display)
struct exynos_dp_device *dp = display->ctx;
int ret;

+   /* Keep the panel disabled while we configure video */
+   if (dp->panel) {
+   if (drm_panel_disable(dp->panel))
+   DRM_ERROR("failed to disable the panel\n");
+   }
+
ret = exynos_dp_detect_hpd(dp);
if (ret) {
/* Cable has been disconnected, we're done */
@@ -917,6 +921,12 @@ static void exynos_dp_commit(struct exynos_drm_display 
*display)
ret = exynos_dp_config_video(dp);
if (ret)
dev_err(dp->dev, "unable to config video\n");
+
+   /* Safe to enable the panel now */
+   if (dp->panel) {
+   if (drm_panel_enable(dp->panel))
+   DRM_ERROR("failed to enable the panel\n");
+   }
 }

 static enum drm_connector_status exynos_dp_detect(
@@ -941,15 +951,18 @@ static int exynos_dp_get_modes(struct drm_connector 
*connector)
struct exynos_dp_device *dp = ctx_from_connector(connector);
struct drm_display_mode *mode;

+   if (dp->panel)
+   return drm_panel_get_modes(dp->panel);
+
mode = drm_mode_create(connector->dev);
if (!mode) {
DRM_ERROR("failed to create a new display mode.\n");
return 0;
}

-   drm_display_mode_from_videomode(>panel.vm, mode);
-   mode->width_mm = dp->panel.width_mm;
-   mode->height_mm = dp->panel.height_mm;
+   drm_display_mode_from_videomode(>priv.vm, mode);
+   mode->width_mm = dp->priv.width_mm;
+   mode->height_mm = dp->priv.height_mm;
connector->display_info.width_mm = mode->width_mm;
connector->display_info.height_mm = mode->height_mm;

@@ -1029,7 +1042,10 @@ static int exynos_dp_create_connector(struct 
exynos_drm_display *display,
drm_connector_register(connector);
drm_mode_connector_attach_encoder(connector, encoder);

-   return 0;
+   if (dp->panel)
+   ret = drm_panel_attach(dp->panel, >connector);
+
+   return ret;
 }

 static void exynos_dp_phy_init(struct exynos_dp_device *dp)
@@ -1065,6 +1081,13 @@ static void exynos_dp_poweron(struct exynos_drm_display 
*display)
if (dp->dpms_mode == DRM_MODE_DPMS_ON)
return;

+   if (dp->panel) {
+   if (drm_panel_prepare(dp->panel)) {
+   DRM_ERROR("failed to setup the panel\n");
+   return;
+   }
+   }
+
clk_prepare_enable(dp->clock);
exynos_dp_phy_init(dp);
exynos_dp_init_dp(dp);
@@ -1079,10 +1102,22 @@ static void exynos_dp_poweroff(struct 
exynos_drm_display *display)
if (dp->dpms_mode != DRM_MODE_DPMS_ON)
return;

+   if (dp->panel) {
+   if (drm_panel_disable(dp->panel)) {
+   DRM_ERROR("failed to disable the panel\n");
+   return;
+   }
+   }
+
disable_irq(dp->irq);
flush_work(>hotplug_work);
exynos_dp_phy_exit(dp);
clk_disable_unprepare(dp->clock);
+
+   if (dp->panel) {
+   if 

[PATCH 14/15] drm/exynos: Move DP setup into commit()

[Ajay Kumar]

Add commit callback for exynos_dp, and move the DP link training,
video configuration code from the hotplug handler into commit().

Signed-off-by: Sean Paul 
Signed-off-by: Ajay Kumar 
---
 drivers/gpu/drm/exynos/exynos_dp_core.c |   24 +++-
 1 file changed, 19 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 31c3de9..347dec9 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -875,10 +875,18 @@ static irqreturn_t exynos_dp_irq_handler(int irq, void 
*arg)
 static void exynos_dp_hotplug(struct work_struct *work)
 {
struct exynos_dp_device *dp;
-   int ret;

dp = container_of(work, struct exynos_dp_device, hotplug_work);

+   if (dp->drm_dev)
+   drm_helper_hpd_irq_event(dp->drm_dev);
+}
+
+static void exynos_dp_commit(struct exynos_drm_display *display)
+{
+   struct exynos_dp_device *dp = display->ctx;
+   int ret;
+
ret = exynos_dp_detect_hpd(dp);
if (ret) {
/* Cable has been disconnected, we're done */
@@ -1050,8 +1058,10 @@ static void exynos_dp_phy_exit(struct exynos_dp_device 
*dp)
}
 }

-static void exynos_dp_poweron(struct exynos_dp_device *dp)
+static void exynos_dp_poweron(struct exynos_drm_display *display)
 {
+   struct exynos_dp_device *dp = display->ctx;
+
if (dp->dpms_mode == DRM_MODE_DPMS_ON)
return;

@@ -1059,10 +1069,13 @@ static void exynos_dp_poweron(struct exynos_dp_device 
*dp)
exynos_dp_phy_init(dp);
exynos_dp_init_dp(dp);
enable_irq(dp->irq);
+   exynos_dp_commit(display);
 }

-static void exynos_dp_poweroff(struct exynos_dp_device *dp)
+static void exynos_dp_poweroff(struct exynos_drm_display *display)
 {
+   struct exynos_dp_device *dp = display->ctx;
+
if (dp->dpms_mode != DRM_MODE_DPMS_ON)
return;

@@ -1078,12 +1091,12 @@ static void exynos_dp_dpms(struct exynos_drm_display 
*display, int mode)

switch (mode) {
case DRM_MODE_DPMS_ON:
-   exynos_dp_poweron(dp);
+   exynos_dp_poweron(display);
break;
case DRM_MODE_DPMS_STANDBY:
case DRM_MODE_DPMS_SUSPEND:
case DRM_MODE_DPMS_OFF:
-   exynos_dp_poweroff(dp);
+   exynos_dp_poweroff(display);
break;
default:
break;
@@ -1094,6 +1107,7 @@ static void exynos_dp_dpms(struct exynos_drm_display 
*display, int mode)
 static struct exynos_drm_display_ops exynos_dp_display_ops = {
.create_connector = exynos_dp_create_connector,
.dpms = exynos_dp_dpms,
+   .commit = exynos_dp_commit,
 };

 static struct exynos_drm_display exynos_dp_display = {
-- 
1.7.9.5

[PATCH 13/15] drm/panel: simple: Add support for auo_b133htn01 panel

[Ajay Kumar]

Add panel_desc structure for auo_b133htn01 eDP panel.

Signed-off-by: Ajay Kumar 
---
 .../devicetree/bindings/panel/auo,b133htn01.txt|7 +
 drivers/gpu/drm/panel/panel-simple.c   |   31 
 2 files changed, 38 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/panel/auo,b133htn01.txt

diff --git a/Documentation/devicetree/bindings/panel/auo,b133htn01.txt 
b/Documentation/devicetree/bindings/panel/auo,b133htn01.txt
new file mode 100644
index 000..302226b
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/auo,b133htn01.txt
@@ -0,0 +1,7 @@
+AU Optronics Corporation 13.3" FHD (1920x1080) color TFT-LCD panel
+
+Required properties:
+- compatible: should be "auo,b133htn01"
+
+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 d6e92ea..a4fa7c7 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -166,6 +166,7 @@ static int panel_simple_prepare(struct drm_panel *panel)
return err;
}

+
if (p->enable_gpio)
gpiod_set_value_cansleep(p->enable_gpio, 1);

@@ -372,6 +373,33 @@ static const struct panel_desc auo_b133xtn01 = {
},
 };

+static const struct drm_display_mode auo_b133htn01_mode = {
+   .clock = 150660,
+   .hdisplay = 1920,
+   .hsync_start = 1920 + 172,
+   .hsync_end = 1920 + 172 + 80,
+   .htotal = 1920 + 172 + 80 + 60,
+   .vdisplay = 1080,
+   .vsync_start = 1080 + 25,
+   .vsync_end = 1080 + 25 + 10,
+   .vtotal = 1080 + 25 + 10 + 10,
+   .vrefresh = 60,
+};
+
+static const struct panel_desc auo_b133htn01 = {
+   .modes = _b133htn01_mode,
+   .num_modes = 1,
+   .size = {
+   .width = 293,
+   .height = 165,
+   },
+   .delay = {
+   .prepare = 105,
+   .enable = 20,
+   .unprepare = 50,
+   },
+};
+
 static const struct drm_display_mode chunghwa_claa101wa01a_mode = {
.clock = 72070,
.hdisplay = 1366,
@@ -511,6 +539,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "auo,b101aw03",
.data = _b101aw03,
}, {
+   .compatible = "auo,b133htn01",
+   .data = _b133htn01,
+   }, {
.compatible = "auo,b133xtn01",
.data = _b133xtn01,
}, {
-- 
1.7.9.5

[PATCH 12/15] drm/panel: simple: Support usage of delays in panel functions

[Ajay Kumar]

For most of the panels, we need to provide delays during
various stages of panel powerup/powerdown.

So, Add a structure to hold those delay values and use them
in corresponding functions.

Signed-off-by: Ajay Kumar 
---
 drivers/gpu/drm/panel/panel-simple.c |   30 ++
 1 file changed, 30 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 9801728..d6e92ea 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -41,6 +41,24 @@ struct panel_desc {
unsigned int width;
unsigned int height;
} size;
+
+   /**
+* @prepare: the time (in milliseconds) that it takes for the panel
+*  to become ready and start receiving video data
+* @enable: the time (in milliseconds) that it takes for the panel
+*  to display the first valid frame after starting to
+*  receive video data
+* @disable: the time (in milliseconds) that it takes for the panel
+*  to turn the display off (no content is visible)
+* @unprepare: the time (in milliseconds) that it takes for the panel
+*  to power down itself completely
+*/
+   struct {
+   unsigned int prepare;
+   unsigned int enable;
+   unsigned int disable;
+   unsigned int unprepare;
+   } delay;
 };

 struct panel_simple {
@@ -106,6 +124,9 @@ static int panel_simple_disable(struct drm_panel *panel)
backlight_update_status(p->backlight);
}

+   if (p->desc->delay.disable)
+   msleep(p->desc->delay.disable);
+
p->enabled = false;

return 0;
@@ -123,6 +144,9 @@ static int panel_simple_unprepare(struct drm_panel *panel)

regulator_disable(p->supply);

+   if (p->desc->delay.unprepare)
+   msleep(p->desc->delay.unprepare);
+
p->prepared = false;

return 0;
@@ -145,6 +169,9 @@ static int panel_simple_prepare(struct drm_panel *panel)
if (p->enable_gpio)
gpiod_set_value_cansleep(p->enable_gpio, 1);

+   if (p->desc->delay.prepare)
+   msleep(p->desc->delay.prepare);
+
p->prepared = true;

return 0;
@@ -157,6 +184,9 @@ static int panel_simple_enable(struct drm_panel *panel)
if (p->enabled)
return 0;

+   if (p->desc->delay.enable)
+   msleep(p->desc->delay.enable);
+
if (p->backlight) {
p->backlight->props.power = FB_BLANK_UNBLANK;
backlight_update_status(p->backlight);
-- 
1.7.9.5

[PATCH 11/15] drm/panel: simple: Add proper definition for prepare and unprepare

[Ajay Kumar]

Move out code from enable and disable routines to prepare
and unprepare routines, so that functionality is properly
distributed across all the panel functions.

Signed-off-by: Ajay Kumar 
---
 drivers/gpu/drm/panel/panel-simple.c |   37 +-
 1 file changed, 27 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 2e51c34..9801728 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -45,6 +45,7 @@ struct panel_desc {

 struct panel_simple {
struct drm_panel base;
+   bool prepared;
bool enabled;

const struct panel_desc *desc;
@@ -105,10 +106,6 @@ static int panel_simple_disable(struct drm_panel *panel)
backlight_update_status(p->backlight);
}

-   if (p->enable_gpio)
-   gpiod_set_value_cansleep(p->enable_gpio, 0);
-
-   regulator_disable(p->supply);
p->enabled = false;

return 0;
@@ -116,20 +113,27 @@ static int panel_simple_disable(struct drm_panel *panel)

 static int panel_simple_unprepare(struct drm_panel *panel)
 {
-   return 0;
-}
+   struct panel_simple *p = to_panel_simple(panel);
+
+   if (!p->prepared)
+   return 0;
+
+   if (p->enable_gpio)
+   gpiod_set_value_cansleep(p->enable_gpio, 0);
+
+   regulator_disable(p->supply);
+
+   p->prepared = false;

-static int panel_simple_prepare(struct drm_panel *panel)
-{
return 0;
 }

-static int panel_simple_enable(struct drm_panel *panel)
+static int panel_simple_prepare(struct drm_panel *panel)
 {
struct panel_simple *p = to_panel_simple(panel);
int err;

-   if (p->enabled)
+   if (p->prepared)
return 0;

err = regulator_enable(p->supply);
@@ -141,6 +145,18 @@ static int panel_simple_enable(struct drm_panel *panel)
if (p->enable_gpio)
gpiod_set_value_cansleep(p->enable_gpio, 1);

+   p->prepared = true;
+
+   return 0;
+}
+
+static int panel_simple_enable(struct drm_panel *panel)
+{
+   struct panel_simple *p = to_panel_simple(panel);
+
+   if (p->enabled)
+   return 0;
+
if (p->backlight) {
p->backlight->props.power = FB_BLANK_UNBLANK;
backlight_update_status(p->backlight);
@@ -191,6 +207,7 @@ static int panel_simple_probe(struct device *dev, const 
struct panel_desc *desc)
return -ENOMEM;

panel->enabled = false;
+   panel->prepared = false;
panel->desc = desc;

panel->supply = devm_regulator_get(dev, "power");
-- 
1.7.9.5

[PATCH 10/15] drm/panel: s6e8aa0: Add proper definition for prepare and unprepare

[Ajay Kumar]

Move out code from enable and disable routines to prepare
and unprepare routines, so that functionality is properly
distributed across all the panel functions.

Signed-off-by: Ajay Kumar 
---
 drivers/gpu/drm/panel/panel-s6e8aa0.c |   22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-s6e8aa0.c 
b/drivers/gpu/drm/panel/panel-s6e8aa0.c
index 60694dd..cf4be7f 100644
--- a/drivers/gpu/drm/panel/panel-s6e8aa0.c
+++ b/drivers/gpu/drm/panel/panel-s6e8aa0.c
@@ -889,6 +889,11 @@ static int s6e8aa0_power_off(struct s6e8aa0 *ctx)

 static int s6e8aa0_disable(struct drm_panel *panel)
 {
+   return 0;
+}
+
+static int s6e8aa0_unprepare(struct drm_panel *panel)
+{
struct s6e8aa0 *ctx = panel_to_s6e8aa0(panel);

s6e8aa0_dcs_write_seq_static(ctx, MIPI_DCS_ENTER_SLEEP_MODE);
@@ -900,18 +905,8 @@ static int s6e8aa0_disable(struct drm_panel *panel)
return s6e8aa0_power_off(ctx);
 }

-static int s6e8aa0_unprepare(struct drm_panel *panel)
-{
-   return 0;
-}
-
 static int s6e8aa0_prepare(struct drm_panel *panel)
 {
-   return 0;
-}
-
-static int s6e8aa0_enable(struct drm_panel *panel)
-{
struct s6e8aa0 *ctx = panel_to_s6e8aa0(panel);
int ret;

@@ -923,11 +918,16 @@ static int s6e8aa0_enable(struct drm_panel *panel)
ret = ctx->error;

if (ret < 0)
-   s6e8aa0_disable(panel);
+   s6e8aa0_unprepare(panel);

return ret;
 }

+static int s6e8aa0_enable(struct drm_panel *panel)
+{
+   return 0;
+}
+
 static int s6e8aa0_get_modes(struct drm_panel *panel)
 {
struct drm_connector *connector = panel->connector;
-- 
1.7.9.5

[PATCH 09/15] drm/panel: ld9040: Add proper definition for prepare and unprepare

[Ajay Kumar]

Move out code from enable and disable routines to prepare
and unprepare routines, so that functionality is properly
distributed across all the panel functions.

Signed-off-by: Ajay Kumar 
---
 drivers/gpu/drm/panel/panel-ld9040.c |   22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-ld9040.c 
b/drivers/gpu/drm/panel/panel-ld9040.c
index 9b40bd05..c6aa7f7 100644
--- a/drivers/gpu/drm/panel/panel-ld9040.c
+++ b/drivers/gpu/drm/panel/panel-ld9040.c
@@ -216,6 +216,11 @@ static int ld9040_power_off(struct ld9040 *ctx)

 static int ld9040_disable(struct drm_panel *panel)
 {
+   return 0;
+}
+
+static int ld9040_unprepare(struct drm_panel *panel)
+{
struct ld9040 *ctx = panel_to_ld9040(panel);

msleep(120);
@@ -228,18 +233,8 @@ static int ld9040_disable(struct drm_panel *panel)
return ld9040_power_off(ctx);
 }

-static int ld9040_unprepare(struct drm_panel *panel)
-{
-   return 0;
-}
-
 static int ld9040_prepare(struct drm_panel *panel)
 {
-   return 0;
-}
-
-static int ld9040_enable(struct drm_panel *panel)
-{
struct ld9040 *ctx = panel_to_ld9040(panel);
int ret;

@@ -252,11 +247,16 @@ static int ld9040_enable(struct drm_panel *panel)
ret = ld9040_clear_error(ctx);

if (ret < 0)
-   ld9040_disable(panel);
+   ld9040_unprepare(panel);

return ret;
 }

+static int ld9040_enable(struct drm_panel *panel)
+{
+   return 0;
+}
+
 static int ld9040_get_modes(struct drm_panel *panel)
 {
struct drm_connector *connector = panel->connector;
-- 
1.7.9.5

[PATCH 08/15] drm/tegra: Add support for panel prepare and unprepare routines

[Ajay Kumar]

Modify tegra output driver to support the new panel calls:
prepare and unprepare.

Signed-off-by: Ajay Kumar 
---
 drivers/gpu/drm/tegra/output.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
index 446837e..0c67d7e 100644
--- a/drivers/gpu/drm/tegra/output.c
+++ b/drivers/gpu/drm/tegra/output.c
@@ -140,7 +140,9 @@ static void tegra_encoder_dpms(struct drm_encoder *encoder, 
int mode)
if (mode != DRM_MODE_DPMS_ON) {
drm_panel_disable(panel);
tegra_output_disable(output);
+   drm_panel_unprepare(panel);
} else {
+   drm_panel_prepare(panel);
tegra_output_enable(output);
drm_panel_enable(panel);
}
-- 
1.7.9.5

[PATCH 07/15] drm/exynos: dsi: Add support for panel prepare and unprepare routines

[Ajay Kumar]

Modify exynos_dsi driver to support the new panel calls:
prepare and unprepare.

Signed-off-by: Ajay Kumar 
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c |   12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index dc7c80b..4834932 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1351,7 +1351,7 @@ static int exynos_dsi_enable(struct exynos_dsi *dsi)
if (ret < 0)
return ret;

-   ret = drm_panel_enable(dsi->panel);
+   ret = drm_panel_prepare(dsi->panel);
if (ret < 0) {
exynos_dsi_poweroff(dsi);
return ret;
@@ -1360,6 +1360,13 @@ static int exynos_dsi_enable(struct exynos_dsi *dsi)
exynos_dsi_set_display_mode(dsi);
exynos_dsi_set_display_enable(dsi, true);

+   ret = drm_panel_enable(dsi->panel);
+   if (ret < 0) {
+   exynos_dsi_set_display_enable(dsi, false);
+   exynos_dsi_poweroff(dsi);
+   return ret;
+   }
+
dsi->state |= DSIM_STATE_ENABLED;

return 0;
@@ -1370,8 +1377,9 @@ static void exynos_dsi_disable(struct exynos_dsi *dsi)
if (!(dsi->state & DSIM_STATE_ENABLED))
return;

-   exynos_dsi_set_display_enable(dsi, false);
drm_panel_disable(dsi->panel);
+   exynos_dsi_set_display_enable(dsi, false);
+   drm_panel_unprepare(dsi->panel);
exynos_dsi_poweroff(dsi);

dsi->state &= ~DSIM_STATE_ENABLED;
-- 
1.7.9.5

[PATCH 06/15] drm/exynos: dpi: Add support for panel prepare and unprepare routines

[Ajay Kumar]

Modify exynos_dpi driver to support the new panel calls:
prepare and unprepare.

Signed-off-by: Ajay Kumar 
---
 drivers/gpu/drm/exynos/exynos_drm_dpi.c |8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
index 3aa1c7e..fa08f05 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
@@ -125,14 +125,18 @@ static int exynos_dpi_create_connector(struct 
exynos_drm_display *display,

 static void exynos_dpi_poweron(struct exynos_dpi *ctx)
 {
-   if (ctx->panel)
+   if (ctx->panel) {
+   drm_panel_prepare(ctx->panel);
drm_panel_enable(ctx->panel);
+   }
 }

 static void exynos_dpi_poweroff(struct exynos_dpi *ctx)
 {
-   if (ctx->panel)
+   if (ctx->panel) {
drm_panel_disable(ctx->panel);
+   drm_panel_unprepare(ctx->panel);
+   }
 }

 static void exynos_dpi_dpms(struct exynos_drm_display *display, int mode)
-- 
1.7.9.5

[PATCH 05/15] drm/panel: simple: Add dummy prepare and unprepare routines

[Ajay Kumar]

This patch adds dummy definition for prepare and unprepare
routines to simple panel driver.

Signed-off-by: Ajay Kumar 
---
 drivers/gpu/drm/panel/panel-simple.c |   12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index a251361..2e51c34 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -114,6 +114,16 @@ static int panel_simple_disable(struct drm_panel *panel)
return 0;
 }

+static int panel_simple_unprepare(struct drm_panel *panel)
+{
+   return 0;
+}
+
+static int panel_simple_prepare(struct drm_panel *panel)
+{
+   return 0;
+}
+
 static int panel_simple_enable(struct drm_panel *panel)
 {
struct panel_simple *p = to_panel_simple(panel);
@@ -164,6 +174,8 @@ static int panel_simple_get_modes(struct drm_panel *panel)

 static const struct drm_panel_funcs panel_simple_funcs = {
.disable = panel_simple_disable,
+   .unprepare = panel_simple_unprepare,
+   .prepare = panel_simple_prepare,
.enable = panel_simple_enable,
.get_modes = panel_simple_get_modes,
 };
-- 
1.7.9.5

[PATCH 04/15] drm/panel: s6e8aa0: Add dummy prepare and unprepare routines

[Ajay Kumar]

This patch adds dummy definition for prepare and unprepare
routines to s6e8aa0 panel driver.

Signed-off-by: Ajay Kumar 
---
 drivers/gpu/drm/panel/panel-s6e8aa0.c |   12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-s6e8aa0.c 
b/drivers/gpu/drm/panel/panel-s6e8aa0.c
index 06e57a2..60694dd 100644
--- a/drivers/gpu/drm/panel/panel-s6e8aa0.c
+++ b/drivers/gpu/drm/panel/panel-s6e8aa0.c
@@ -900,6 +900,16 @@ static int s6e8aa0_disable(struct drm_panel *panel)
return s6e8aa0_power_off(ctx);
 }

+static int s6e8aa0_unprepare(struct drm_panel *panel)
+{
+   return 0;
+}
+
+static int s6e8aa0_prepare(struct drm_panel *panel)
+{
+   return 0;
+}
+
 static int s6e8aa0_enable(struct drm_panel *panel)
 {
struct s6e8aa0 *ctx = panel_to_s6e8aa0(panel);
@@ -944,6 +954,8 @@ static int s6e8aa0_get_modes(struct drm_panel *panel)

 static const struct drm_panel_funcs s6e8aa0_drm_funcs = {
.disable = s6e8aa0_disable,
+   .unprepare = s6e8aa0_unprepare,
+   .prepare = s6e8aa0_prepare,
.enable = s6e8aa0_enable,
.get_modes = s6e8aa0_get_modes,
 };
-- 
1.7.9.5

[PATCH 03/15] drm/panel: ld9040: Add dummy prepare and unprepare routines

[Ajay Kumar]

This patch adds dummy definition for prepare and unprepare
routines to ld9040 panel driver.

Signed-off-by: Ajay Kumar 
---
 drivers/gpu/drm/panel/panel-ld9040.c |   12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-ld9040.c 
b/drivers/gpu/drm/panel/panel-ld9040.c
index db1601f..9b40bd05 100644
--- a/drivers/gpu/drm/panel/panel-ld9040.c
+++ b/drivers/gpu/drm/panel/panel-ld9040.c
@@ -228,6 +228,16 @@ static int ld9040_disable(struct drm_panel *panel)
return ld9040_power_off(ctx);
 }

+static int ld9040_unprepare(struct drm_panel *panel)
+{
+   return 0;
+}
+
+static int ld9040_prepare(struct drm_panel *panel)
+{
+   return 0;
+}
+
 static int ld9040_enable(struct drm_panel *panel)
 {
struct ld9040 *ctx = panel_to_ld9040(panel);
@@ -273,6 +283,8 @@ static int ld9040_get_modes(struct drm_panel *panel)

 static const struct drm_panel_funcs ld9040_drm_funcs = {
.disable = ld9040_disable,
+   .unprepare = ld9040_unprepare,
+   .prepare = ld9040_prepare,
.enable = ld9040_enable,
.get_modes = ld9040_get_modes,
 };
-- 
1.7.9.5

[PATCH 02/15] drm/panel: Add get_modes helper

[Ajay Kumar]

Add a helper function drm_panel_get_modes to get modes from the panel.

Signed-off-by: Ajay Kumar 
---
 include/drm/drm_panel.h |8 
 1 file changed, 8 insertions(+)

diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
index 9addc69..efc63cc 100644
--- a/include/drm/drm_panel.h
+++ b/include/drm/drm_panel.h
@@ -80,6 +80,14 @@ static inline int drm_panel_enable(struct drm_panel *panel)
return panel ? -ENOSYS : -EINVAL;
 }

+static inline int drm_panel_get_modes(struct drm_panel *panel)
+{
+   if (panel && panel->funcs && panel->funcs->get_modes)
+   return panel->funcs->get_modes(panel);
+
+   return 0;
+}
+
 void drm_panel_init(struct drm_panel *panel);

 int drm_panel_add(struct drm_panel *panel);
-- 
1.7.9.5

[PATCH 01/15] drm/panel: add prepare and unprepare routines

[Ajay Kumar]

Most of the panels need an init sequence as mentioned below:
-- poweron LCD unit/LCD_EN
-- start video data
-- poweron LED unit/BACKLIGHT_EN
And, a de-init sequence as mentioned below:
-- poweroff LED unit/BACKLIGHT_EN
-- stop video data
-- poweroff LCD unit/LCD_EN
With existing callbacks for drm panel, we cannot accomodate such panels,
since only two callbacks, i.e "panel_enable" and panel_disable are supported.

This patch adds:
-- "prepare" callback which can be called before
the actual video data is on, and then call the "enable"
callback after the video data is available.

-- "unprepare" callback which can be called after
the video data is off, and use "disable" callback
to do something before switching off the video data.

Now, we can easily map the above scenario as shown below:
poweron LCD unit/LCD_EN = "prepare" callback
poweron LED unit/BACKLIGHT_EN = "enable" callback
poweroff LED unit/BACKLIGHT_EN = "disable" callback
poweroff LCD unit/LCD_EN = "unprepare" callback

Signed-off-by: Ajay Kumar 
---
 include/drm/drm_panel.h |   18 ++
 1 file changed, 18 insertions(+)

diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
index c2ab77a..9addc69 100644
--- a/include/drm/drm_panel.h
+++ b/include/drm/drm_panel.h
@@ -31,7 +31,9 @@ struct drm_device;
 struct drm_panel;

 struct drm_panel_funcs {
+   int (*unprepare)(struct drm_panel *panel);
int (*disable)(struct drm_panel *panel);
+   int (*prepare)(struct drm_panel *panel);
int (*enable)(struct drm_panel *panel);
int (*get_modes)(struct drm_panel *panel);
 };
@@ -46,6 +48,14 @@ struct drm_panel {
struct list_head list;
 };

+static inline int drm_panel_unprepare(struct drm_panel *panel)
+{
+   if (panel && panel->funcs && panel->funcs->unprepare)
+   return panel->funcs->unprepare(panel);
+
+   return panel ? -ENOSYS : -EINVAL;
+}
+
 static inline int drm_panel_disable(struct drm_panel *panel)
 {
if (panel && panel->funcs && panel->funcs->disable)
@@ -54,6 +64,14 @@ static inline int drm_panel_disable(struct drm_panel *panel)
return panel ? -ENOSYS : -EINVAL;
 }

+static inline int drm_panel_prepare(struct drm_panel *panel)
+{
+   if (panel && panel->funcs && panel->funcs->prepare)
+   return panel->funcs->prepare(panel);
+
+   return panel ? -ENOSYS : -EINVAL;
+}
+
 static inline int drm_panel_enable(struct drm_panel *panel)
 {
if (panel && panel->funcs && panel->funcs->enable)
-- 
1.7.9.5

[PATCH 00/15] drm/panel: Add prepare and unprepare routines

[Ajay Kumar]

This series is based on exynos-drm-next branch of Inki Dae's tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git

This is originally a part of the bridge chip series:
http://www.spinics.net/lists/linux-samsung-soc/msg34826.html

But, since we can handle panel and bridge chips seperately,
I thought of seperating them.

This patchset basically extends the drm panel framework
to accomodate wider range of panels with strict timing
sequence for enabling panel power, backlight enable, etc.

I have tested this patchset on exynos5800-peach-pi board.

Thierry:
As discussed, I have seperated patches such that they
won't break the compilation in between. Also, I have
incorporated all the comments given by you for panel patches.
I assume you have already taken [PATCH 01/15] and hence
it can be dropped from this patchset.

Ajay Kumar (15):
  [PATCH 01/15] drm/panel: add prepare and unprepare routines
  [PATCH 02/15] drm/panel: Add get_modes helper
  [PATCH 03/15] drm/panel: ld9040: Add dummy prepare and unprepare routines
  [PATCH 04/15] drm/panel: s6e8aa0: Add dummy prepare and unprepare routines
  [PATCH 05/15] drm/panel: simple: Add dummy prepare and unprepare routines
  [PATCH 06/15] drm/exynos: dpi: Add support for panel prepare and unprepare 
routines
  [PATCH 07/15] drm/exynos: dsi: Add support for panel prepare and unprepare 
routines
  [PATCH 08/15] drm/tegra: Add support for panel prepare and unprepare routines
  [PATCH 09/15] drm/panel: ld9040: Add proper definition for prepare and 
unprepare
  [PATCH 10/15] drm/panel: s6e8aa0: Add proper definition for prepare and 
unprepare
  [PATCH 11/15] drm/panel: simple: Add proper definition for prepare and 
unprepare
  [PATCH 12/15] drm/panel: simple: Support usage of delays in panel functions
  [PATCH 13/15] drm/panel: simple: Add support for auo_b133htn01 panel
  [PATCH 14/15] drm/exynos: Move DP setup into commit()
  [PATCH 15/15] drm/exynos: dp: Modify driver to support drm_panel

 .../devicetree/bindings/panel/auo,b133htn01.txt|7 ++
 drivers/gpu/drm/exynos/Kconfig |1 +
 drivers/gpu/drm/exynos/exynos_dp_core.c|  112 +++-
 drivers/gpu/drm/exynos/exynos_dp_core.h|3 +-
 drivers/gpu/drm/exynos/exynos_drm_dpi.c|8 +-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c|   12 ++-
 drivers/gpu/drm/panel/panel-ld9040.c   |   16 ++-
 drivers/gpu/drm/panel/panel-s6e8aa0.c  |   16 ++-
 drivers/gpu/drm/panel/panel-simple.c   |   96 -
 drivers/gpu/drm/tegra/output.c |2 +
 include/drm/drm_panel.h|   26 +
 11 files changed, 262 insertions(+), 37 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/panel/auo,b133htn01.txt

-- 
1.7.9.5