[Bug 194761] amdgpu driver breaks on Oland (SI)

[bugzilla-daemon]

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

--- Comment #82 from Zoltan Boszormenyi (zbos...@pr.hu) ---
This might be a related fix from Jean Delvare:
https://lists.freedesktop.org/archives/dri-devel/2017-July/148751.html

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/6] drm/bridge: tc358767: fixes and improvements

[Archit Taneja]

On 07/27/2017 06:17 PM, Andrey Gusakov wrote:

This set of patches fixes several issues that was found during testing
tc358767 with desktop DisplayPort displays.


These changes look good to me.

Philipp, can I get your Ack on these?

Thanks,
Archit



Andrey Gusakov (6):
   drm/bridge: tc358767: do no fail on hi-res displays
   drm/bridge: tc358767: filter out too high modes
   drm/bridge: tc358767: fix DP0_MISC register set
   drm/bridge: tc358767: fix timing calculations
   drm/bridge: tc358767: fix AUXDATAn registers access
   drm/bridge: tc358767: fix 1-lane behavior

  drivers/gpu/drm/bridge/tc358767.c | 73 +--
  1 file changed, 40 insertions(+), 33 deletions(-)



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/3] drm: Widen vblank UAPI to 64 bits. Change vblank time to ktime_t [v2]

[Keith Packard]

This modifies the datatypes used by the vblank code to provide both 64
bits of vblank count and switch to using ktime_t for timestamps to
increase resolution from microseconds to nanoseconds.

The driver interfaces have been left using 32 bits of vblank count;
all of the code necessary to widen that value for the user API was
already included to handle devices returning fewer than 32-bits.

This will provide the necessary datatypes for the Vulkan API.

v2:

 * Re-write wait_vblank ioctl to ABSOLUTE sequence

When an application uses the WAIT_VBLANK ioctl with RELATIVE
or NEXTONMISS bits set, the target vblank interval is updated
within the kernel. We need to write that target back to the
ioctl buffer and update the flags bits so that if the wait is
interrupted by a signal, when it is re-started, it will target
precisely the same vblank count as before.

 * Leave driver API with 32-bit vblank count

Suggested-by:  Michel Dänzer 
Suggested-by: Daniel Vetter 
Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/drm_vblank.c | 186 +--
 include/drm/drmP.h   |   2 +-
 include/drm/drm_drv.h|   2 +-
 include/drm/drm_vblank.h |  16 ++--
 4 files changed, 120 insertions(+), 86 deletions(-)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 463e4d81fb0d..346601ad698d 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -43,7 +43,7 @@
 
 static bool
 drm_get_last_vbltimestamp(struct drm_device *dev, unsigned int pipe,
- struct timeval *tvblank, bool in_vblank_irq);
+ ktime_t *tvblank, bool in_vblank_irq);
 
 static unsigned int drm_timestamp_precision = 20;  /* Default to 20 usecs. */
 
@@ -64,7 +64,7 @@ MODULE_PARM_DESC(timestamp_monotonic, "Use monotonic 
timestamps");
 
 static void store_vblank(struct drm_device *dev, unsigned int pipe,
 u32 vblank_count_inc,
-struct timeval *t_vblank, u32 last)
+ktime_t t_vblank, u32 last)
 {
struct drm_vblank_crtc *vblank = >vblank[pipe];
 
@@ -73,7 +73,7 @@ static void store_vblank(struct drm_device *dev, unsigned int 
pipe,
vblank->last = last;
 
write_seqlock(>seqlock);
-   vblank->time = *t_vblank;
+   vblank->time = t_vblank;
vblank->count += vblank_count_inc;
write_sequnlock(>seqlock);
 }
@@ -116,7 +116,7 @@ static void drm_reset_vblank_timestamp(struct drm_device 
*dev, unsigned int pipe
 {
u32 cur_vblank;
bool rc;
-   struct timeval t_vblank;
+   ktime_t t_vblank;
int count = DRM_TIMESTAMP_MAXRETRIES;
 
spin_lock(>vblank_time_lock);
@@ -136,13 +136,13 @@ static void drm_reset_vblank_timestamp(struct drm_device 
*dev, unsigned int pipe
 * interrupt and assign 0 for now, to mark the vblanktimestamp as 
invalid.
 */
if (!rc)
-   t_vblank = (struct timeval) {0, 0};
+   t_vblank = 0;
 
/*
 * +1 to make sure user will never see the same
 * vblank counter value before and after a modeset
 */
-   store_vblank(dev, pipe, 1, _vblank, cur_vblank);
+   store_vblank(dev, pipe, 1, t_vblank, cur_vblank);
 
spin_unlock(>vblank_time_lock);
 }
@@ -165,7 +165,7 @@ static void drm_update_vblank_count(struct drm_device *dev, 
unsigned int pipe,
struct drm_vblank_crtc *vblank = >vblank[pipe];
u32 cur_vblank, diff;
bool rc;
-   struct timeval t_vblank;
+   ktime_t t_vblank;
int count = DRM_TIMESTAMP_MAXRETRIES;
int framedur_ns = vblank->framedur_ns;
 
@@ -190,11 +190,9 @@ static void drm_update_vblank_count(struct drm_device 
*dev, unsigned int pipe,
/* trust the hw counter when it's around */
diff = (cur_vblank - vblank->last) & dev->max_vblank_count;
} else if (rc && framedur_ns) {
-   const struct timeval *t_old;
-   u64 diff_ns;
+   ktime_t diff_ns;
 
-   t_old = >time;
-   diff_ns = timeval_to_ns(_vblank) - timeval_to_ns(t_old);
+   diff_ns = t_vblank - vblank->time;
 
/*
 * Figure out how many vblanks we've missed based
@@ -228,7 +226,7 @@ static void drm_update_vblank_count(struct drm_device *dev, 
unsigned int pipe,
}
 
DRM_DEBUG_VBL("updating vblank count on crtc %u:"
- " current=%u, diff=%u, hw=%u hw_last=%u\n",
+ " current=%llu, diff=%u, hw=%u hw_last=%u\n",
  pipe, vblank->count, diff, cur_vblank, vblank->last);
 
if (diff == 0) {
@@ -243,9 +241,9 @@ static void drm_update_vblank_count(struct drm_device *dev, 
unsigned int pipe,
 * for now, to mark the vblanktimestamp as invalid.
 

[PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2]

[Keith Packard]

These provide crtc-id based functions instead of pipe-number, while
also offering higher resolution time (ns) and wider frame count (64)
as required by the Vulkan API.

v2:

 * Check for DRIVER_MODESET in new crtc-based vblank ioctls

Failing to check this will oops the driver.

 * Ensure vblank interupt is running in crtc_get_sequence ioctl

The sequence and timing values are not correct while the
interrupt is off, so make sure it's running before asking for
them.

 * Short-circuit get_sequence if the counter is enabled and accurate

Steal the idea from the code in wait_vblank to avoid the
expense of drm_vblank_get/put

 * Return active state of crtc in crtc_get_sequence ioctl

Might be useful for applications that aren't in charge of
modesetting?

 * Use drm_crtc_vblank_get/put in new crtc-based vblank sequence ioctls

Daniel Vetter prefers these over the old drm_vblank_put/get
APIs.

 * Return s64 ns instead of u64 in new sequence event

Suggested-by:  Daniel Vetter 
Suggested-by: Ville Syrjälä 
Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/drm_internal.h |   6 ++
 drivers/gpu/drm/drm_ioctl.c|   2 +
 drivers/gpu/drm/drm_vblank.c   | 173 +
 include/drm/drm_vblank.h   |   1 +
 include/uapi/drm/drm.h |  32 
 5 files changed, 214 insertions(+)

diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 5cecc974d2f9..b68a193b7907 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -65,6 +65,12 @@ int drm_legacy_irq_control(struct drm_device *dev, void 
*data,
 int drm_legacy_modeset_ctl(struct drm_device *dev, void *data,
   struct drm_file *file_priv);
 
+int drm_crtc_get_sequence_ioctl(struct drm_device *dev, void *data,
+   struct drm_file *filp);
+
+int drm_crtc_queue_sequence_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *filp);
+
 /* drm_auth.c */
 int drm_getmagic(struct drm_device *dev, void *data,
 struct drm_file *file_priv);
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index f1e568176da9..63016cf3e224 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -657,6 +657,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
  DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE, 
drm_syncobj_fd_to_handle_ioctl,
  DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF(DRM_IOCTL_CRTC_GET_SEQUENCE, drm_crtc_get_sequence_ioctl, 
DRM_UNLOCKED),
+   DRM_IOCTL_DEF(DRM_IOCTL_CRTC_QUEUE_SEQUENCE, 
drm_crtc_queue_sequence_ioctl, DRM_UNLOCKED),
 };
 
 #define DRM_CORE_IOCTL_COUNT   ARRAY_SIZE( drm_ioctls )
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 7e7119a5ada3..69b8c92cdd3a 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -812,6 +812,11 @@ static void send_vblank_event(struct drm_device *dev,
e->event.vbl.tv_sec = tv.tv_sec;
e->event.vbl.tv_usec = tv.tv_usec;
break;
+   case DRM_EVENT_CRTC_SEQUENCE:
+   if (seq)
+   e->event.seq.sequence = seq;
+   e->event.seq.time_ns = ktime_to_ns(now);
+   break;
}
trace_drm_vblank_event_delivered(e->base.file_priv, e->pipe, seq);
drm_send_event_locked(dev, >base);
@@ -1682,3 +1687,171 @@ bool drm_crtc_handle_vblank(struct drm_crtc *crtc)
return drm_handle_vblank(crtc->dev, drm_crtc_index(crtc));
 }
 EXPORT_SYMBOL(drm_crtc_handle_vblank);
+
+/*
+ * Get crtc VBLANK count.
+ *
+ * \param dev DRM device
+ * \param data user arguement, pointing to a drm_crtc_get_sequence structure.
+ * \param file_priv drm file private for the user's open file descriptor
+ */
+
+int drm_crtc_get_sequence_ioctl(struct drm_device *dev, void *data,
+   struct drm_file *file_priv)
+{
+   struct drm_crtc *crtc;
+   struct drm_vblank_crtc *vblank;
+   int pipe;
+   struct drm_crtc_get_sequence *get_seq = data;
+   ktime_t now;
+   bool vblank_enabled;
+   int ret;
+
+   if (!drm_core_check_feature(dev, DRIVER_MODESET))
+   return -EINVAL;
+
+   if (!dev->irq_enabled)
+   return -EINVAL;
+
+   crtc = drm_crtc_find(dev, get_seq->crtc_id);
+   if (!crtc)
+   return -ENOENT;
+
+   pipe = drm_crtc_index(crtc);
+
+   vblank = >vblank[pipe];
+   vblank_enabled = dev->vblank_disable_immediate && 
READ_ONCE(vblank->enabled);
+
+   if (!vblank_enabled) {
+   ret = drm_crtc_vblank_get(crtc);
+   if (ret) {
+   DRM_DEBUG("crtc %d failed to 

[PATCH 2/3] drm: Reorganize drm_pending_event to support future event types [v2]

[Keith Packard]

Place drm_event_vblank in a new union that includes that and a bare
drm_event structure. This will allow new members of that union to be
added in the future without changing code related to the existing vbl
event type.

Assignments to the crtc_id field are now done when the event is
allocated, rather than when delievered. This way, delivery doesn't
need to have the crtc ID available.

v2:
 * Remove 'dev' argument from create_vblank_event

It wasn't being used anyways, and if we need it in the future,
we can always get it from crtc->dev.

 * Check for MODESETTING before looking for crtc in queue_vblank_event

UMS drivers will oops if we try to get a crtc, so make sure
we're modesetting before we try to find a crtc_id to fill into
the event.

Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/drm_atomic.c |  7 ---
 drivers/gpu/drm/drm_plane.c  |  2 +-
 drivers/gpu/drm/drm_vblank.c | 30 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c |  4 ++--
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c |  4 ++--
 include/drm/drm_vblank.h |  8 +++-
 6 files changed, 34 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index c0f336d23f9c..272b83ea9369 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1839,7 +1839,7 @@ int drm_atomic_debugfs_init(struct drm_minor *minor)
  */
 
 static struct drm_pending_vblank_event *create_vblank_event(
-   struct drm_device *dev, uint64_t user_data)
+   struct drm_crtc *crtc, uint64_t user_data)
 {
struct drm_pending_vblank_event *e = NULL;
 
@@ -1849,7 +1849,8 @@ static struct drm_pending_vblank_event 
*create_vblank_event(
 
e->event.base.type = DRM_EVENT_FLIP_COMPLETE;
e->event.base.length = sizeof(e->event);
-   e->event.user_data = user_data;
+   e->event.vbl.crtc_id = crtc->base.id;
+   e->event.vbl.user_data = user_data;
 
return e;
 }
@@ -2052,7 +2053,7 @@ static int prepare_crtc_signaling(struct drm_device *dev,
if (arg->flags & DRM_MODE_PAGE_FLIP_EVENT || fence_ptr) {
struct drm_pending_vblank_event *e;
 
-   e = create_vblank_event(dev, arg->user_data);
+   e = create_vblank_event(crtc, arg->user_data);
if (!e)
return -ENOMEM;
 
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 5dc8c4350602..fe9f31285bc2 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -918,7 +918,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
}
e->event.base.type = DRM_EVENT_FLIP_COMPLETE;
e->event.base.length = sizeof(e->event);
-   e->event.user_data = page_flip->user_data;
+   e->event.vbl.user_data = page_flip->user_data;
ret = drm_event_reserve_init(dev, file_priv, >base, 
>event.base);
if (ret) {
kfree(e);
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 346601ad698d..7e7119a5ada3 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -804,14 +804,16 @@ static void send_vblank_event(struct drm_device *dev,
 {
struct timeval tv;
 
-   tv = ktime_to_timeval(now);
-   e->event.sequence = seq;
-   e->event.tv_sec = tv.tv_sec;
-   e->event.tv_usec = tv.tv_usec;
-
-   trace_drm_vblank_event_delivered(e->base.file_priv, e->pipe,
-e->event.sequence);
-
+   switch (e->event.base.type) {
+   case DRM_EVENT_VBLANK:
+   case DRM_EVENT_FLIP_COMPLETE:
+   tv = ktime_to_timeval(now);
+   e->event.vbl.sequence = seq;
+   e->event.vbl.tv_sec = tv.tv_sec;
+   e->event.vbl.tv_usec = tv.tv_usec;
+   break;
+   }
+   trace_drm_vblank_event_delivered(e->base.file_priv, e->pipe, seq);
drm_send_event_locked(dev, >base);
 }
 
@@ -863,7 +865,6 @@ void drm_crtc_arm_vblank_event(struct drm_crtc *crtc,
 
e->pipe = pipe;
e->sequence = drm_vblank_count(dev, pipe);
-   e->event.crtc_id = crtc->base.id;
list_add_tail(>base.link, >vblank_event_list);
 }
 EXPORT_SYMBOL(drm_crtc_arm_vblank_event);
@@ -894,7 +895,6 @@ void drm_crtc_send_vblank_event(struct drm_crtc *crtc,
now = get_drm_timestamp();
}
e->pipe = pipe;
-   e->event.crtc_id = crtc->base.id;
send_vblank_event(dev, e, seq, now);
 }
 EXPORT_SYMBOL(drm_crtc_send_vblank_event);
@@ -1354,8 +1354,14 @@ static int drm_queue_vblank_event(struct drm_device 
*dev, unsigned int pipe,
 
e->pipe = pipe;
e->event.base.type = DRM_EVENT_VBLANK;
-   e->event.base.length = sizeof(e->event);
-   

[PATCH 0/3] drm: Add CRTC-id based ioctls for vblank query/event

[Keith Packard]

Here's an updated series for the proposed new IOCTLs. Major changes
since last time:

 * Leave driver API with 32-bit vblank counts
 * Use ktime_t instead of struct timespec.
 * Check for MODESETTING before using modesetting APIs
 * Ensure vblank is running in new get_sequence ioctl

There are other minor changes noted in each patch.

Thanks to helpful review from:

Daniel Vetter 
Michel Dänzer 
Ville Syrjälä 

-keith

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

[Bug 101996] Having problems when drawing lots of mesh with texture array

[bugzilla-daemon]

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

Bug ID: 101996
   Summary: Having problems when drawing lots of mesh with texture
array
   Product: Mesa
   Version: 17.2
  Hardware: Other
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: benau2...@yahoo.com.hk
QA Contact: dri-devel@lists.freedesktop.org

Hi,

I'm developing a new engine for game STK, and is having serious regression when
switching to use texture array for drawing meshes in game:

Code:
https://github.com/Benau/stk-code/tree/sp_new
(Basically only data/shader/sp*.* and src/sp/* is relevant

Assets:
https://github.com/Benau/sp-assets
(In case if real-time testing is needed)

Apitrace:
http://kobato.stan.hk/bug.trace.lzma

Linux is 4.12.4
DRM is using git
Mesa version  is 17.2.0-rc1 (git-a455f594bb)

So when you enter the game with lots of meshes rendering, the game is spending
a lot of time waiting in glFlush,
(~100ms at worst)
in util_queue_fence_wait in gdb with ctrl-c,
Full trace:

#0  pthread_cond_wait@@GLIBC_2.3.2 () at
../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x7f85d8c30d22 in cnd_wait (cond=0x1ca8d50, mtx=0x1ca8d28) at
../../include/c11/threads_posix.h:159
#2  0x7f85d8c31221 in util_queue_fence_wait (fence=0x1ca8d28) at
u_queue.c:106
#3  0x7f85d90bc6c3 in radeon_drm_cs_sync_flush (rcs=0x1c80b70) at
radeon_drm_cs.c:489
#4  0x7f85d90bcb20 in radeon_drm_cs_flush (rcs=0x1c80b70, flags=1,
pfence=0x1ad97e8) at radeon_drm_cs.c:614
#5  0x7f85d9078f00 in si_context_gfx_flush (context=0x1ad9430, flags=1,
fence=0x0) at si_hw_context.c:154
#6  0x7f85d90fff53 in r600_flush_from_st (ctx=0x1ad9430, fence=0x0,
flags=0) at r600_pipe_common.c:396
#7  0x7f85d8d8fb30 in tc_flush (_pipe=0x1ca8da0, fence=0x0, flags=0) at
util/u_threaded_context.c:1799
#8  0x7f85d8ada3ec in st_flush (st=0x1ce2300, fence=0x0, flags=0) at
state_tracker/st_cb_flush.c:87
#9  0x7f85d8ada4b3 in st_glFlush (ctx=0x1cb0ec0) at
state_tracker/st_cb_flush.c:121
#10 0x7f85d884cff5 in _mesa_flush (ctx=0x1cb0ec0) at main/context.c:1846
#11 0x7seriousf85d884d17d in _mesa_Flush () at main/context.c:1884
#12 0x00f649ce in irr::video::COpenGLDriver::endScene (this=0x1cfe410)
at /data/game/stk-code/lib/irrlicht/source/Irrlicht/COpenGLDriver.cpp:908
(As you can see in apitrace)


When something bad-luck enough, it can even hang / lock the whole linux, this
is the before journalctl:
8月 01 10:55:52 kobato kernel: [TTM] Failed allocating page table
8月 01 10:55:52 kobato kernel: [TTM] Buffer eviction failed
8月 01 10:55:52 kobato kernel: [TTM] Failed allocating page table
8月 01 10:55:52 kobato kernel: [TTM] Buffer eviction failed
8月 01 10:55:52 kobato kernel: BUG: unable to handle kernel NULL pointer
dereference at 00b8
8月 01 10:55:52 kobato kernel: IP: drm_mm_remove_node+0x280/0x2c0
8月 01 10:55:52 kobato kernel: PGD 295f96067 
8月 01 10:55:52 kobato kernel: P4D 295f96067 
8月 01 10:55:52 kobato kernel: PUD 20e4a1067 
8月 01 10:55:52 kobato kernel: PMD 0 
8月 01 10:55:52 kobato kernel: 
8月 01 10:55:52 kobato kernel: Oops: 0002 [#1] PREEMPT SMP
8月 01 10:55:52 kobato kernel: Modules linked in: ctr ccm ipt_MASQUERADE
nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4
nf_nat nf_conntrack af_packet fuse月 01 10:55:52 kobato kernel: CPU: 5 PID: 4349
Comm: radeon_cs:0 Tainted: G   O4.12.4 #4
8月 01 10:55:52 kobato kernel: Hardware name: To Be Filled By O.E.M. To Be
Filled By O.E.M./Z87 Pro4, BIOS P2.30 07/11/2014
8月 01 10:55:52 kobato kernel: task: 88010c9f8c00 task.stack:
c9000ee1c000
8月 01 10:55:52 kobato kernel: RIP: 0010:drm_mm_remove_node+0x280/0x2c0
8月 01 10:55:52 kobato kernel: RSP: 0018:c9000ee1f600 EFLAGS: 00010246
8月 01 10:55:52 kobato kernel: RAX:  RBX: 07d8 RCX:
00020002
8月 01 10:55:52 kobato kernel: RDX:  RSI: c9000ee1f668 RDI:

8月 01 10:55:52 kobato kernel: RBP: 88011f267780 R08:  R09:
88011f2677c0
8月 01 10:55:52 kobato kernel: R10: ea00047c99c0 R11:  R12:
07f8
8月 01 10:55:52 kobato kernel: R13:  R14: 88030ff70980 R15:
88020e7f9068
8月 01 10:55:52 kobato kernel: FS:  7f7ee903d700()
GS:88031ed4() knlGS:
8月 01 10:55:52 kobato kernel: CS:  0010 DS:  ES:  CR0: 80050033
8月 01 10:55:52 kobato kernel: CR2: 00b8 CR3: 000297b41000 CR4:
001406a0
8月 01 10:55:52 kobato kernel: Call Trace:
8月 01 10:55:52 kobato kernel:  ? ttm_bo_man_put_node+0x26/0x50
8月 01 10:55:52 kobato kernel:  ? ttm_bo_evict+0x156/0x2a0
8月 01 10:55:52 kobato kernel:  ? ttm_mem_evict_first+0x137/0x190
8月 01 10:55:52 kobato kernel:  

Re: enable adbd over tcp in terminal before surfaceflinger

[zhoucm1]

+ dri-devel, maybe other guys know it.


On 2017年08月01日 00:15, Chih-Wei Huang wrote:

I want to enable tcp adb in terminal before surfaceflinger, since in some
cases, adb cannot connect over tcp if surfaceflinger crash or dead off.
I have tried several things:
  Android7 doesn't have netcfg and dhcpcd binary, so I pushed these two
commands to system.
with 'netcfg eth0 up' and 'netcfg eth0 dhcp', I can get IP address, but
client cannot connect to this ip(time out).

and when running 'netcfg eth0 dhcp', the terminal will output failed log
"action 'dhcp' failed (Network is unreachable)".

What do you think of it? Is there a know method to enable tcp adb in
terminal without depending on framework?

Honestly speaking I didn't try that.
I'll give a try later.


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

[PATCHv4 3/3] DRM:ivip Intel FPGA Video and Image Processing Suite

[Hean Loong, Ong]

From: Ong Hean Loong 

Driver for Intel FPGA Video and Image Processing
Suite Frame Buffer II. The driver only supports the Intel
Arria10 devkit and its variants. This driver can be either
loaded staticlly or in modules. The OF device tree binding
is located at:
Documentation/devicetree/bindings/display/altr,vip-fb2.txt

Signed-off-by: Ong, Hean Loong 
---
V3:
*Changes to fixing drm_simple_pipe
*Used drm_fb_cma_get_gem_addr

V2:
*Adding drm_simple_display_pipe_init
---
 drivers/gpu/drm/Kconfig   |   2 +
 drivers/gpu/drm/Makefile  |   1 +
 drivers/gpu/drm/ivip/Kconfig  |  13 +++
 drivers/gpu/drm/ivip/Makefile |   9 ++
 drivers/gpu/drm/ivip/intel_vip_conn.c |  96 
 drivers/gpu/drm/ivip/intel_vip_core.c | 183 ++
 drivers/gpu/drm/ivip/intel_vip_drv.h  |  54 +
 drivers/gpu/drm/ivip/intel_vip_of.c   | 204 ++
 8 files changed, 562 insertions(+)
 create mode 100644 drivers/gpu/drm/ivip/Kconfig
 create mode 100644 drivers/gpu/drm/ivip/Makefile
 create mode 100644 drivers/gpu/drm/ivip/intel_vip_conn.c
 create mode 100644 drivers/gpu/drm/ivip/intel_vip_core.c
 create mode 100644 drivers/gpu/drm/ivip/intel_vip_drv.h
 create mode 100644 drivers/gpu/drm/ivip/intel_vip_of.c

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 83cb2a8..38a184d 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -195,6 +195,8 @@ source "drivers/gpu/drm/nouveau/Kconfig"
 
 source "drivers/gpu/drm/i915/Kconfig"
 
+source "drivers/gpu/drm/ivip/Kconfig"
+
 config DRM_VGEM
tristate "Virtual GEM provider"
depends on DRM
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 24a066e..4162a0e 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -58,6 +58,7 @@ obj-$(CONFIG_DRM_AMDGPU)+= amd/amdgpu/
 obj-$(CONFIG_DRM_MGA)  += mga/
 obj-$(CONFIG_DRM_I810) += i810/
 obj-$(CONFIG_DRM_I915) += i915/
+obj-$(CONFIG_DRM_IVIP) += ivip/
 obj-$(CONFIG_DRM_MGAG200) += mgag200/
 obj-$(CONFIG_DRM_VC4)  += vc4/
 obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus/
diff --git a/drivers/gpu/drm/ivip/Kconfig b/drivers/gpu/drm/ivip/Kconfig
new file mode 100644
index 000..9a8c5ce
--- /dev/null
+++ b/drivers/gpu/drm/ivip/Kconfig
@@ -0,0 +1,13 @@
+config DRM_IVIP
+tristate "Intel FGPA Video and Image Processing"
+depends on DRM && OF
+select DRM_GEM_CMA_HELPER
+select DRM_KMS_HELPER
+select DRM_KMS_FB_HELPER
+select DRM_KMS_CMA_HELPER
+help
+Choose this option if you have a Intel FPGA Arria 10 system
+and above with a Display Port IP. This does not support legacy
+Intel FPGA Cyclone V display port. Currently only single frame
+buffer is supported. Note that ACPI and X_86 architecture is yet
+to be supported.If M is selected the module would be called ivip.
diff --git a/drivers/gpu/drm/ivip/Makefile b/drivers/gpu/drm/ivip/Makefile
new file mode 100644
index 000..95291c6
--- /dev/null
+++ b/drivers/gpu/drm/ivip/Makefile
@@ -0,0 +1,9 @@
+#
+# Makefile for the drm device driver.  This driver provides support for the
+# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
+
+ccflags-y := -Iinclude/drm
+
+obj-$(CONFIG_DRM_IVIP) += ivip.o
+ivip-objs := intel_vip_of.o intel_vip_core.o \
+intel_vip_conn.o
diff --git a/drivers/gpu/drm/ivip/intel_vip_conn.c 
b/drivers/gpu/drm/ivip/intel_vip_conn.c
new file mode 100644
index 000..063d91e
--- /dev/null
+++ b/drivers/gpu/drm/ivip/intel_vip_conn.c
@@ -0,0 +1,96 @@
+/*
+ * intel_vip_conn.c -- Intel Video and Image Processing(VIP)
+ * Frame Buffer II driver
+ *
+ * This driver supports the Intel VIP Frame Reader component.
+ * More info on the hardware can be found in the Intel Video
+ * and Image Processing Suite User Guide at this address
+ * http://www.altera.com/literature/ug/ug_vip.pdf.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * Authors:
+ * Ong, Hean-Loong 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static enum drm_connector_status
+intelvipfb_drm_connector_detect(struct drm_connector *connector, bool force)
+{
+   return connector_status_connected;
+}
+
+static void intelvipfb_drm_connector_destroy(struct drm_connector *connector)
+{
+   drm_connector_unregister(connector);
+   drm_connector_cleanup(connector);
+}
+
+static const struct 

[PATCHv4 2/3] ARM:socfpga-defconfig Intel FPGA Video and Image Processing Suite

[Hean Loong, Ong]

From: Ong Hean Loong 

Intel FPGA Video and Image Processing Suite Frame Buffer II
driver config for Arria 10 devkit and its variants

Signed-off-by: Ong, Hean Loong 
---
 arch/arm/configs/socfpga_defconfig | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/configs/socfpga_defconfig 
b/arch/arm/configs/socfpga_defconfig
index 2620ce7..255f553 100644
--- a/arch/arm/configs/socfpga_defconfig
+++ b/arch/arm/configs/socfpga_defconfig
@@ -111,6 +111,12 @@ CONFIG_MFD_ALTERA_A10SR=y
 CONFIG_MFD_STMPE=y
 CONFIG_REGULATOR=y
 CONFIG_REGULATOR_FIXED_VOLTAGE=y
+CONFIG_DRM=m
+CONFIG_DRM_IVIP=m
+CONFIG_DRM_IVIP_OF=m
+CONFIG_FB=y
+CONFIG_FB_SIMPLE=y
+CONFIG_FRAMEBUFFER_CONSOLE=m
 CONFIG_USB=y
 CONFIG_USB_STORAGE=y
 CONFIG_USB_DWC2=y
-- 
2.7.4

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

[PATCHv4 1/3] ARM:dt-bindings Intel FPGA Video and Image Processing Suite

[Hean Loong, Ong]

From: Ong Hean Loong 

Device tree binding for Intel FPGA Video and Image
Processing Suite. The binding involved would be generated
from the Altera (Intel) Qsys system. The bindings would
set the max width, max height, buts per pixel and memory
port width. The device tree binding only supports the Intel
Arria10 devkit and its variants. Vendor name retained as
altr.

Signed-off-by: Ong, Hean Loong 
---
 .../devicetree/bindings/display/altr,vip-fb2.txt   | 39 ++
 1 file changed, 39 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/altr,vip-fb2.txt

diff --git a/Documentation/devicetree/bindings/display/altr,vip-fb2.txt 
b/Documentation/devicetree/bindings/display/altr,vip-fb2.txt
new file mode 100644
index 000..c4338d9
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/altr,vip-fb2.txt
@@ -0,0 +1,39 @@
+Intel Video and Image Processing(VIP) Frame Buffer II bindings
+
+Supported hardware: Arria 10 and above with display port IP
+
+The hardware associated with this device tree is a SoC FPGA. Where there is an 
ARM controller
+and a FPGA device. The ARM controller would host the Linux OS while the FPGA 
device runs on its
+individual IP firmware. In the Intel VIP Frame Buffer II the ARM controller 
would be
+driving data from the Linux OS to the FPGA device programmed with the Frame 
Buffer II IP
+to render pixels to be streamed to the Display Port connector.
+
+The Frame Buffer II device is a simple frame buffer device. The device 
contains the display
+properties and the bridge or connector register. The output for this device 
currently
+is a dedicated to a single Display Port. Currently the max resolution 
supported is 1280 x 720 at
+60Hz.
+
+More information the FPGA video IP component can be acquired from
+https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/ug/ug_vip.pdf
+
+
+New bindings:
+=
+Required properties:
+
+- compatible: "altr,vip-frame-buffer-2.0"
+- reg: Physical base address and length of the framebuffer controller's
+  registers.
+- altr,max-width: The width of the framebuffer in pixels.
+- altr,max-height: The height of the framebuffer in pixels.
+- altr,mem-port-width = the bus width of the avalon master port on the frame 
reader
+
+Example:
+
+   dp_0_frame_buf: display-controller@10280 {
+   compatible = "altr,vip-frame-buffer-2.0";
+   reg = <0x0001 0x0280 0x0040>;
+   altr,max-width = <1280>;
+   altr,max-height = <720>;
+   altr,mem-port-width = <128>;
+   };
-- 
2.7.4

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

[PATCHv4 0/3] Intel FPGA VIP Frame Buffer II drm driver

[Hean Loong, Ong]

From: Ong Hean Loong 

The FPGA FrameBuffer Soft IP could be seen  as the GPU and the DRM driver patch 
here is allocating memory for  information to be streamed from the ARM/Linux to 
the display port.
Basically the driver just wraps the information such as the pixels to  be drawn 
by the FPGA FrameBuffer 2.
 
The piece of hardware in discussion is the SoC FPGA where Linux runs  on the 
ARM chip and the FGPA is driven by its NIOS soft core with its  own proprietary 
firmware.
 
 For example the application from the ARM Linux would have to write  
information on the /dev/fb0 with the information stored in the SDRAM  to be 
fetched by the FPGA framebuffer IP and displayed on the Display  Port Monitor.


Ong Hean Loong (3):
  ARM:dt-bindings Intel FPGA Video and Image Processing Suite
  ARM:socfpga-defconfig Intel FPGA Video and Image Processing Suite
  DRM:ivip Intel FPGA Video and Image Processing Suite

 .../devicetree/bindings/display/altr,vip-fb2.txt   |  39 
 arch/arm/configs/socfpga_defconfig |   6 +
 drivers/gpu/drm/Kconfig|   2 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/ivip/Kconfig   |  13 ++
 drivers/gpu/drm/ivip/Makefile  |   9 +
 drivers/gpu/drm/ivip/intel_vip_conn.c  |  96 ++
 drivers/gpu/drm/ivip/intel_vip_core.c  | 183 ++
 drivers/gpu/drm/ivip/intel_vip_drv.h   |  54 ++
 drivers/gpu/drm/ivip/intel_vip_of.c| 204 +
 10 files changed, 607 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/altr,vip-fb2.txt
 create mode 100644 drivers/gpu/drm/ivip/Kconfig
 create mode 100644 drivers/gpu/drm/ivip/Makefile
 create mode 100644 drivers/gpu/drm/ivip/intel_vip_conn.c
 create mode 100644 drivers/gpu/drm/ivip/intel_vip_core.c
 create mode 100644 drivers/gpu/drm/ivip/intel_vip_drv.h
 create mode 100644 drivers/gpu/drm/ivip/intel_vip_of.c

-- 
2.7.4

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

[Bug 97882] [amdgpu SI] amdgpu on SI devices is much slower then radeon

[bugzilla-daemon]

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

Trevor Davenport  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 97882] [amdgpu SI] amdgpu on SI devices is much slower then radeon

[bugzilla-daemon]

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

--- Comment #7 from Trevor Davenport  ---
This is fixed by the following commit:


author  Jean Delvare  2017-07-30 08:18:25 (GMT)
committer   Alex Deucher 2017-07-31
20:30:42 (GMT)
commit  e5c8d400da67abc1c033b9a4af1806926b55e5f6 (patch)
treecf3dac459890ed900416d4087ae0603d4aa42b6f
parent  29805b5f60d88c56ae7e91ae231f0ff8bf1983b8 (diff)

drm/amdgpu: Fix undue fallthroughs in golden registers initialization

As I was staring at the si_init_golden_registers code, I noticed that
the Pitcairn initialization silently falls through the Cape Verde
initialization, and the Oland initialization falls through the Hainan
initialization. However there is no comment stating that this is
intentional, and the radeon driver doesn't have any such fallthrough,
so I suspect this is not supposed to happen.

Commit can be seen here:
https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.14-wip=e5c8d400da67abc1c033b9a4af1806926b55e5f6

With this fix I now get performance approximately equal to that of radeon.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] dma-buf: fix reservation_object_wait_timeout_rcu to wait correctly v2

[zhoucm1]

On 2017年07月31日 23:39, Deucher, Alexander wrote:

-Original Message-
From: Christian König [mailto:deathsim...@vodafone.de]
Sent: Monday, July 31, 2017 10:13 AM
To: linux-me...@vger.kernel.org; dri-devel@lists.freedesktop.org; linaro-
mm-...@lists.linaro.org; Zhou, David(ChunMing); Deucher, Alexander
Subject: Re: [PATCH] dma-buf: fix reservation_object_wait_timeout_rcu to
wait correctly v2

Ping, what do you guys think of that?

Seems reasonable to me.
Reviewed-by: Alex Deucher 

Reviewed-by: Chunming Zhou  as well.




Am 25.07.2017 um 15:35 schrieb Christian König:

From: Christian König 

With hardware resets in mind it is possible that all shared fences are
signaled, but the exlusive isn't. Fix waiting for everything in this situation.

v2: make sure we always wait for the exclusive fence

Signed-off-by: Christian König 
---
   drivers/dma-buf/reservation.c | 33 +++--
   1 file changed, 15 insertions(+), 18 deletions(-)

diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index 393817e..9d4316d 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -373,12 +373,25 @@ long reservation_object_wait_timeout_rcu(struct

reservation_object *obj,

long ret = timeout ? timeout : 1;

   retry:
-   fence = NULL;
shared_count = 0;
seq = read_seqcount_begin(>seq);
rcu_read_lock();

-   if (wait_all) {
+   fence = rcu_dereference(obj->fence_excl);
+   if (fence && !test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, 
flags)) {
+   if (!dma_fence_get_rcu(fence))
+   goto unlock_retry;
+
+   if (dma_fence_is_signaled(fence)) {
+   dma_fence_put(fence);
+   fence = NULL;
+   }
+
+   } else {
+   fence = NULL;
+   }
+
+   if (!fence && wait_all) {
struct reservation_object_list *fobj =
rcu_dereference(obj-
fence);

@@ -405,22 +418,6 @@ long reservation_object_wait_timeout_rcu(struct

reservation_object *obj,

}
}

-   if (!shared_count) {
-   struct dma_fence *fence_excl = rcu_dereference(obj-
fence_excl);
-
-   if (fence_excl &&
-   !test_bit(DMA_FENCE_FLAG_SIGNALED_BIT,
- _excl->flags)) {
-   if (!dma_fence_get_rcu(fence_excl))
-   goto unlock_retry;
-
-   if (dma_fence_is_signaled(fence_excl))
-   dma_fence_put(fence_excl);
-   else
-   fence = fence_excl;
-   }
-   }
-
rcu_read_unlock();
if (fence) {
if (read_seqcount_retry(>seq, seq)) {


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

Re: [PATCH 6/6] drm/rockchip: fix race with kms hotplug and fbdev

[Mark yao]

On 2017年07月31日 20:28, Daniel Vetter wrote:

On Mon, Jul 31, 2017 at 1:57 PM, Emil Velikov  wrote:

On 31 July 2017 at 10:50, Mark Yao  wrote:

Since fb_helper is not a pointer on rockchip_drm_private, it's no
need to check pointer.

Kms hotplug event may race into fbdev helper initial, and fb_helper->dev
may be NULL pointer, that would cause the bug:

[0.735411] [0200] *pgd=f6ffe003, *pud=f6ffe003, 
*pmd=
[0.736156] Internal error: Oops: 9605 [#1] PREEMPT SMP
[0.736648] Modules linked in:
[0.736930] CPU: 2 PID: 20 Comm: kworker/2:0 Not tainted 4.4.41 #20
[0.737480] Hardware name: Rockchip RK3399 Board rev2 (BOX) (DT)
[0.738020] Workqueue: events cdn_dp_pd_event_work
[0.738447] task: ffc0f21f3100 ti: ffc0f2218000 task.ti: 
ffc0f2218000
[0.739109] PC is at mutex_lock+0x14/0x44
[0.739469] LR is at drm_fb_helper_hotplug_event+0x30/0x114
[0.756253] [] mutex_lock+0x14/0x44
[0.756260] [] drm_fb_helper_hotplug_event+0x30/0x114
[0.756271] [] rockchip_drm_output_poll_changed+0x18/0x20
[0.756280] [] drm_kms_helper_hotplug_event+0x28/0x34
[0.756286] [] cdn_dp_pd_event_work+0x394/0x3c4
[0.756295] [] process_one_work+0x218/0x3e0
[0.756302] [] worker_thread+0x2e8/0x404
[0.756308] [] kthread+0xe8/0xf0
[0.756316] [] ret_from_fork+0x10/0x40

Signed-off-by: Mark Yao 
---
  drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index 81f9548..e6bd0f4 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -170,7 +170,7 @@ static void rockchip_drm_output_poll_changed(struct 
drm_device *dev)
 struct rockchip_drm_private *private = dev->dev_private;
 struct drm_fb_helper *fb_helper = >fbdev_helper;

-   if (fb_helper)
+   if (fb_helper->dev)
 drm_fb_helper_hotplug_event(fb_helper);

Food for thought:

Quick grep shows that no other drivers have such a ->dev check. Does
this mean that either the issue is rockchip specific?
If not, one could look into resolving the problem directly in drm core.

Or at least update the other users, so they don't stumble upon the problem?

The fbdev helpers support already handling hotplug events before you
have finalized the fbdev setup. Please read the kerneldoc for the
various fbdev functions, they explain what you should be doing. This
hack here should indeed not be needed.
-Daniel


Hi Daniel

Right, the doc[0] already detail this:
It is possible, though perhaps somewhat tricky, to implement race-free 
hotplug detection using
the fbdev helpers. The drm_fb_helper_prepare() helper must be called first 
to initialize the
minimum required to make hotplug detection work.Drivers also need to make 
sure to properly
set up the drm_mode_config.funcs member. After calling 
drm_kms_helper_poll_init() it is safe to
enable interrupts and start processing hotplug events.

The problem is drm/rockchip do the wrong initial, call drm_kms_helper_poll_init 
before fbdev setup.

will fix it at next version.

[0]: 
https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-kms-helpers.html#fbdev-helper-functions-reference

Best regards.

--
Ｍark Yao


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

[Bug 101978] [bisected] war thunder performance reduced by ~28%

[bugzilla-daemon]

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

--- Comment #2 from Michel Dänzer  ---
(In reply to higuita from comment #1)
> Can a apitrace help in anyway to understand why this affects so much this
> game

Possibly.

Also, there are amdgpu kernel driver changes lined up for 4.14 that might help.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101978] [bisected] war thunder performance reduced by ~28%

[bugzilla-daemon]

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

--- Comment #1 from higu...@gmx.net ---
Running some of the other benchmarks, i get this:

Benchmark   goodbad %

patrick 40823173-22
plane   20011793-10
tank (cpu)  13201094-17
tanks   17061431-16

in other benchmarks, the commit did not make much difference, specially on
planes, but on tanks it did a lot, "test drive" with the chi-nu tank (ie: as in
real game play) i get this fps reduction:

chi nu test 25  14  -44%

I also notice that the GPU load also drop mostly in the same degree, but the
sclk get a little higer with more spikes.for the "still scene", where i get
-28% performance, the gpu load drops 32% and about 330-370MHz for before the
commit, but 320-390MHz after the commit

GPU load55  37  -32
sclk  330-370 320-380

Can a apitrace help in anyway to understand why this affects so much this game

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 1/4] drm/bridge: dw-hdmi: add cec notifier support

[Russell King]

Add CEC notifier support to the HDMI bridge driver, so that the CEC
part of the IP can receive its physical address.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/bridge/synopsys/Kconfig   |  1 +
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 22 +-
 2 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/Kconfig 
b/drivers/gpu/drm/bridge/synopsys/Kconfig
index 53e78d092d18..351db000599a 100644
--- a/drivers/gpu/drm/bridge/synopsys/Kconfig
+++ b/drivers/gpu/drm/bridge/synopsys/Kconfig
@@ -2,6 +2,7 @@ config DRM_DW_HDMI
tristate
select DRM_KMS_HELPER
select REGMAP_MMIO
+   select CEC_CORE if CEC_NOTIFIER
 
 config DRM_DW_HDMI_AHB_AUDIO
tristate "Synopsys Designware AHB Audio interface"
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index ead11242c4b9..82e55ee8e4fa 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -36,7 +36,10 @@
 #include "dw-hdmi.h"
 #include "dw-hdmi-audio.h"
 
+#include 
+
 #define DDC_SEGMENT_ADDR   0x30
+
 #define HDMI_EDID_LEN  512
 
 enum hdmi_datamap {
@@ -175,6 +178,8 @@ struct dw_hdmi {
struct regmap *regm;
void (*enable_audio)(struct dw_hdmi *hdmi);
void (*disable_audio)(struct dw_hdmi *hdmi);
+
+   struct cec_notifier *cec_notifier;
 };
 
 #define HDMI_IH_PHY_STAT0_RX_SENSE \
@@ -1896,6 +1901,7 @@ static int dw_hdmi_connector_get_modes(struct 
drm_connector *connector)
hdmi->sink_is_hdmi = drm_detect_hdmi_monitor(edid);
hdmi->sink_has_audio = drm_detect_monitor_audio(edid);
drm_mode_connector_update_edid_property(connector, edid);
+   cec_notifier_set_phys_addr_from_edid(hdmi->cec_notifier, edid);
ret = drm_add_edid_modes(connector, edid);
/* Store the ELD */
drm_edid_to_eld(connector, edid);
@@ -2119,11 +2125,16 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
 * ask the source to re-read the EDID.
 */
if (intr_stat &
-   (HDMI_IH_PHY_STAT0_RX_SENSE | HDMI_IH_PHY_STAT0_HPD))
+   (HDMI_IH_PHY_STAT0_RX_SENSE | HDMI_IH_PHY_STAT0_HPD)) {
__dw_hdmi_setup_rx_sense(hdmi,
 phy_stat & HDMI_PHY_HPD,
 phy_stat & HDMI_PHY_RX_SENSE);
 
+   if ((phy_stat & (HDMI_PHY_RX_SENSE | HDMI_PHY_HPD)) == 0)
+   cec_notifier_set_phys_addr(hdmi->cec_notifier,
+  CEC_PHYS_ADDR_INVALID);
+   }
+
if (intr_stat & HDMI_IH_PHY_STAT0_HPD) {
dev_dbg(hdmi->dev, "EVENT=%s\n",
phy_int_pol & HDMI_PHY_HPD ? "plugin" : "plugout");
@@ -2376,6 +2387,12 @@ __dw_hdmi_probe(struct platform_device *pdev,
if (ret)
goto err_iahb;
 
+   hdmi->cec_notifier = cec_notifier_get(dev);
+   if (!hdmi->cec_notifier) {
+   ret = -ENOMEM;
+   goto err_iahb;
+   }
+
/*
 * To prevent overflows in HDMI_IH_FC_STAT2, set the clk regenerator
 * N and cts values before enabling phy
@@ -2452,6 +2469,9 @@ __dw_hdmi_probe(struct platform_device *pdev,
hdmi->ddc = NULL;
}
 
+   if (hdmi->cec_notifier)
+   cec_notifier_put(hdmi->cec_notifier);
+
clk_disable_unprepare(hdmi->iahb_clk);
 err_isfr:
clk_disable_unprepare(hdmi->isfr_clk);
-- 
2.7.4

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

[PATCH v2 2/4] drm/bridge: dw-hdmi: add better clock disable control

[Russell King]

The video setup path aways sets the clock disable register to a specific
value, which has the effect of disabling the CEC engine.  When we add the
CEC driver, this becomes a problem.

Fix this by only setting/clearing the bits that the video path needs to.

Reviewed-by: Jose Abreu 
Signed-off-by: Russell King 
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 29 ++---
 1 file changed, 18 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 82e55ee8e4fa..b08cc0c95590 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -166,6 +166,7 @@ struct dw_hdmi {
bool bridge_is_on;  /* indicates the bridge is on */
bool rxsense;   /* rxsense state */
u8 phy_mask;/* desired phy int mask settings */
+   u8 mc_clkdis;   /* clock disable register */
 
spinlock_t audio_lock;
struct mutex audio_mutex;
@@ -551,8 +552,11 @@ EXPORT_SYMBOL_GPL(dw_hdmi_set_sample_rate);
 
 static void hdmi_enable_audio_clk(struct dw_hdmi *hdmi, bool enable)
 {
-   hdmi_modb(hdmi, enable ? 0 : HDMI_MC_CLKDIS_AUDCLK_DISABLE,
- HDMI_MC_CLKDIS_AUDCLK_DISABLE, HDMI_MC_CLKDIS);
+   if (enable)
+   hdmi->mc_clkdis &= ~HDMI_MC_CLKDIS_AUDCLK_DISABLE;
+   else
+   hdmi->mc_clkdis |= HDMI_MC_CLKDIS_AUDCLK_DISABLE;
+   hdmi_writeb(hdmi, hdmi->mc_clkdis, HDMI_MC_CLKDIS);
 }
 
 static void dw_hdmi_ahb_audio_enable(struct dw_hdmi *hdmi)
@@ -1574,8 +1578,6 @@ static void hdmi_av_composer(struct dw_hdmi *hdmi,
 /* HDMI Initialization Step B.4 */
 static void dw_hdmi_enable_video_path(struct dw_hdmi *hdmi)
 {
-   u8 clkdis;
-
/* control period minimum duration */
hdmi_writeb(hdmi, 12, HDMI_FC_CTRLDUR);
hdmi_writeb(hdmi, 32, HDMI_FC_EXCTRLDUR);
@@ -1587,17 +1589,21 @@ static void dw_hdmi_enable_video_path(struct dw_hdmi 
*hdmi)
hdmi_writeb(hdmi, 0x21, HDMI_FC_CH2PREAM);
 
/* Enable pixel clock and tmds data path */
-   clkdis = 0x7F;
-   clkdis &= ~HDMI_MC_CLKDIS_PIXELCLK_DISABLE;
-   hdmi_writeb(hdmi, clkdis, HDMI_MC_CLKDIS);
+   hdmi->mc_clkdis |= HDMI_MC_CLKDIS_HDCPCLK_DISABLE |
+  HDMI_MC_CLKDIS_CSCCLK_DISABLE |
+  HDMI_MC_CLKDIS_AUDCLK_DISABLE |
+  HDMI_MC_CLKDIS_PREPCLK_DISABLE |
+  HDMI_MC_CLKDIS_TMDSCLK_DISABLE;
+   hdmi->mc_clkdis &= ~HDMI_MC_CLKDIS_PIXELCLK_DISABLE;
+   hdmi_writeb(hdmi, hdmi->mc_clkdis, HDMI_MC_CLKDIS);
 
-   clkdis &= ~HDMI_MC_CLKDIS_TMDSCLK_DISABLE;
-   hdmi_writeb(hdmi, clkdis, HDMI_MC_CLKDIS);
+   hdmi->mc_clkdis &= ~HDMI_MC_CLKDIS_TMDSCLK_DISABLE;
+   hdmi_writeb(hdmi, hdmi->mc_clkdis, HDMI_MC_CLKDIS);
 
/* Enable csc path */
if (is_color_space_conversion(hdmi)) {
-   clkdis &= ~HDMI_MC_CLKDIS_CSCCLK_DISABLE;
-   hdmi_writeb(hdmi, clkdis, HDMI_MC_CLKDIS);
+   hdmi->mc_clkdis &= ~HDMI_MC_CLKDIS_CSCCLK_DISABLE;
+   hdmi_writeb(hdmi, hdmi->mc_clkdis, HDMI_MC_CLKDIS);
}
 
/* Enable color space conversion if needed */
@@ -2272,6 +2278,7 @@ __dw_hdmi_probe(struct platform_device *pdev,
hdmi->disabled = true;
hdmi->rxsense = true;
hdmi->phy_mask = (u8)~(HDMI_PHY_HPD | HDMI_PHY_RX_SENSE);
+   hdmi->mc_clkdis = 0x7f;
 
mutex_init(>mutex);
mutex_init(>audio_mutex);
-- 
2.7.4

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

Please pull ARCPGU changes

[Alexey Brodkin]

Hi Dave,

Could you please pull a couple of minor fixes for ARCPGU.
These changes are based on today's drm-misc/drm-misc-next.

The following changes since commit 9dd2aca46a13cc7177625f0dc3aaf5b7ebc6fe74:

  drm/rockchip: vop: rk3328: fix overlay abnormal (2017-07-31 08:44:18 +0800)

are available in the git repository at:

  https://github.com/foss-for-synopsys-dwc-arc-processors/linux 
topic-arcpgu-updates

for you to fetch changes up to a8709950755748e9975d63faa624f2ba4b39f9d6:

  drm: arcpgu: Allow some clock deviation in crtc->mode_valid() callback 
(2017-07-31 14:05:21 +0300)


Alexey Brodkin (2):
  drm/arcpgu: Opt in debugfs
  arcpgu: Simplify driver name

Jose Abreu (3):
  drm: arcpgu: Fix mmap() callback
  drm: arcpgu: Fix module unload
  drm: arcpgu: Allow some clock deviation in crtc->mode_valid() callback

 drivers/gpu/drm/arc/arcpgu_crtc.c |  7 ---
 drivers/gpu/drm/arc/arcpgu_drv.c  | 57 
-
 2 files changed, 36 insertions(+), 28 deletions(-)

Regards,
Alexey
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 0/4] dw-hdmi CEC support

[Russell King - ARM Linux]

Hi,

This series adds dw-hdmi CEC support.  This is done in four stages:

1. Add cec-notifier support
2. Fix up the clkdis register support, as this register contains a
   clock disable bit for the CEC module.
3. Add the driver.
4. Remove definitions that are not required from dw-hdmi.h

The CEC driver has been updated to use the register accessors in the
main driver - it would be nice if it was possible to use the regmap
support directly, but there's some knowledge private to the main
driver that's required to correctly access the registers.  (I don't
understand why the register stride isn't part of regmap.)

 drivers/gpu/drm/bridge/synopsys/Kconfig   |  10 +
 drivers/gpu/drm/bridge/synopsys/Makefile  |   1 +
 drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c | 326 ++
 drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.h |  19 ++
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  93 +++-
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.h |  46 +---
 6 files changed, 437 insertions(+), 58 deletions(-)

v2 - fix selection of CEC_NOTIFIER in Kconfig

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 4/4] drm/bridge: dw-hdmi: remove CEC engine register definitions

[Russell King]

We don't need the CEC engine register definitions, so let's remove them.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 45 ---
 1 file changed, 45 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
index 69644c83a0f8..9d90eb9c46e5 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
@@ -478,51 +478,6 @@
 #define HDMI_A_PRESETUP 0x501A
 #define HDMI_A_SRM_BASE 0x5020
 
-/* CEC Engine Registers */
-#define HDMI_CEC_CTRL   0x7D00
-#define HDMI_CEC_STAT   0x7D01
-#define HDMI_CEC_MASK   0x7D02
-#define HDMI_CEC_POLARITY   0x7D03
-#define HDMI_CEC_INT0x7D04
-#define HDMI_CEC_ADDR_L 0x7D05
-#define HDMI_CEC_ADDR_H 0x7D06
-#define HDMI_CEC_TX_CNT 0x7D07
-#define HDMI_CEC_RX_CNT 0x7D08
-#define HDMI_CEC_TX_DATA0   0x7D10
-#define HDMI_CEC_TX_DATA1   0x7D11
-#define HDMI_CEC_TX_DATA2   0x7D12
-#define HDMI_CEC_TX_DATA3   0x7D13
-#define HDMI_CEC_TX_DATA4   0x7D14
-#define HDMI_CEC_TX_DATA5   0x7D15
-#define HDMI_CEC_TX_DATA6   0x7D16
-#define HDMI_CEC_TX_DATA7   0x7D17
-#define HDMI_CEC_TX_DATA8   0x7D18
-#define HDMI_CEC_TX_DATA9   0x7D19
-#define HDMI_CEC_TX_DATA10  0x7D1a
-#define HDMI_CEC_TX_DATA11  0x7D1b
-#define HDMI_CEC_TX_DATA12  0x7D1c
-#define HDMI_CEC_TX_DATA13  0x7D1d
-#define HDMI_CEC_TX_DATA14  0x7D1e
-#define HDMI_CEC_TX_DATA15  0x7D1f
-#define HDMI_CEC_RX_DATA0   0x7D20
-#define HDMI_CEC_RX_DATA1   0x7D21
-#define HDMI_CEC_RX_DATA2   0x7D22
-#define HDMI_CEC_RX_DATA3   0x7D23
-#define HDMI_CEC_RX_DATA4   0x7D24
-#define HDMI_CEC_RX_DATA5   0x7D25
-#define HDMI_CEC_RX_DATA6   0x7D26
-#define HDMI_CEC_RX_DATA7   0x7D27
-#define HDMI_CEC_RX_DATA8   0x7D28
-#define HDMI_CEC_RX_DATA9   0x7D29
-#define HDMI_CEC_RX_DATA10  0x7D2a
-#define HDMI_CEC_RX_DATA11  0x7D2b
-#define HDMI_CEC_RX_DATA12  0x7D2c
-#define HDMI_CEC_RX_DATA13  0x7D2d
-#define HDMI_CEC_RX_DATA14  0x7D2e
-#define HDMI_CEC_RX_DATA15  0x7D2f
-#define HDMI_CEC_LOCK   0x7D30
-#define HDMI_CEC_WKUPCTRL   0x7D31
-
 /* I2C Master Registers (E-DDC) */
 #define HDMI_I2CM_SLAVE 0x7E00
 #define HDMI_I2CM_ADDRESS   0x7E01
-- 
2.7.4

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

[PATCH] Add drm ioctl DRM_IOCTL_MODE_GETFB2 & associated helpers.

[Joe Kniss]

New getfb2 functionality uses drm_mode_fb_cmd2 struct to be symmetric
with addfb2.   Also modifies *_fb_create_handle() calls to accept a
format_plane_index so that handles for each plane can be generated.
Previously, many *_fb_create_handle() calls simply defaulted to plane 0 only.

Signed-off-by: Joe Kniss 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c |  5 +-
 drivers/gpu/drm/armada/armada_fb.c  |  1 +
 drivers/gpu/drm/drm_crtc_internal.h |  2 +
 drivers/gpu/drm/drm_fb_cma_helper.c | 11 ++--
 drivers/gpu/drm/drm_framebuffer.c   | 79 -
 drivers/gpu/drm/drm_ioctl.c |  1 +
 drivers/gpu/drm/exynos/exynos_drm_fb.c  |  7 ++-
 drivers/gpu/drm/gma500/framebuffer.c|  2 +
 drivers/gpu/drm/i915/intel_display.c|  1 +
 drivers/gpu/drm/mediatek/mtk_drm_fb.c   |  1 +
 drivers/gpu/drm/msm/msm_fb.c|  5 +-
 drivers/gpu/drm/nouveau/nouveau_display.c   |  1 +
 drivers/gpu/drm/omapdrm/omap_fb.c   |  5 +-
 drivers/gpu/drm/radeon/radeon_display.c |  5 +-
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c  |  6 ++-
 drivers/gpu/drm/tegra/fb.c  |  9 +++-
 include/drm/drm_framebuffer.h   |  1 +
 include/uapi/drm/drm.h  |  2 +
 18 files changed, 127 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 39fc388f222a..c77c1cd265a0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -566,8 +566,9 @@ static void amdgpu_user_framebuffer_destroy(struct 
drm_framebuffer *fb)
 }
 
 static int amdgpu_user_framebuffer_create_handle(struct drm_framebuffer *fb,
- struct drm_file *file_priv,
- unsigned int *handle)
+unsigned int plane_index,
+struct drm_file *file_priv,
+unsigned int *handle)
 {
struct amdgpu_framebuffer *amdgpu_fb = to_amdgpu_framebuffer(fb);
 
diff --git a/drivers/gpu/drm/armada/armada_fb.c 
b/drivers/gpu/drm/armada/armada_fb.c
index 2a7eb6817c36..9f237544f6c5 100644
--- a/drivers/gpu/drm/armada/armada_fb.c
+++ b/drivers/gpu/drm/armada/armada_fb.c
@@ -23,6 +23,7 @@ static void armada_fb_destroy(struct drm_framebuffer *fb)
 }
 
 static int armada_fb_create_handle(struct drm_framebuffer *fb,
+   unsigned int format_plane_index,
struct drm_file *dfile, unsigned int *handle)
 {
struct armada_framebuffer *dfb = drm_fb_to_armada_fb(fb);
diff --git a/drivers/gpu/drm/drm_crtc_internal.h 
b/drivers/gpu/drm/drm_crtc_internal.h
index 955c5690bf64..ec8d913240fe 100644
--- a/drivers/gpu/drm/drm_crtc_internal.h
+++ b/drivers/gpu/drm/drm_crtc_internal.h
@@ -170,6 +170,8 @@ int drm_mode_rmfb(struct drm_device *dev,
  void *data, struct drm_file *file_priv);
 int drm_mode_getfb(struct drm_device *dev,
   void *data, struct drm_file *file_priv);
+int drm_mode_getfb2(struct drm_device *dev,
+  void *data, struct drm_file *file_priv);
 int drm_mode_dirtyfb_ioctl(struct drm_device *dev,
   void *data, struct drm_file *file_priv);
 
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c
index 596fabf18c3e..5fd7bcc2c6d1 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -110,13 +110,16 @@ void drm_fb_cma_destroy(struct drm_framebuffer *fb)
 }
 EXPORT_SYMBOL(drm_fb_cma_destroy);
 
-int drm_fb_cma_create_handle(struct drm_framebuffer *fb,
-   struct drm_file *file_priv, unsigned int *handle)
+static int drm_fb_cma_create_handle(struct drm_framebuffer *fb,
+   unsigned int format_plane_index,
+   struct drm_file *file_priv,
+   unsigned int *handle)
 {
struct drm_fb_cma *fb_cma = to_fb_cma(fb);
-
+   if (format_plane_index >= 4 || !fb_dma->obj[format_plane_index])
+   return -ENOENT;
return drm_gem_handle_create(file_priv,
-   _cma->obj[0]->base, handle);
+   _cma->obj[format_plane_index]->base, handle);
 }
 EXPORT_SYMBOL(drm_fb_cma_create_handle);
 
diff --git a/drivers/gpu/drm/drm_framebuffer.c 
b/drivers/gpu/drm/drm_framebuffer.c
index 28a0108a1ab8..67b3be1bedbc 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "drm_crtc_internal.h"
 
@@ -438,7 +439,7 @@ int drm_mode_getfb(struct drm_device *dev,
if (fb->funcs->create_handle) {
if (drm_is_current_master(file_priv) || capable(CAP_SYS_ADMIN) 
||
   

[PATCH v2 3/4] drm/bridge: dw-hdmi: add cec driver

[Russell King]

Add a CEC driver for the dw-hdmi hardware.

Reviewed-by: Neil Armstrong 
Signed-off-by: Russell King 
---
 drivers/gpu/drm/bridge/synopsys/Kconfig   |   9 +
 drivers/gpu/drm/bridge/synopsys/Makefile  |   1 +
 drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c | 326 ++
 drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.h |  19 ++
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  42 +++-
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.h |   1 +
 6 files changed, 397 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c
 create mode 100644 drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.h

diff --git a/drivers/gpu/drm/bridge/synopsys/Kconfig 
b/drivers/gpu/drm/bridge/synopsys/Kconfig
index 351db000599a..d34c3dc04ba9 100644
--- a/drivers/gpu/drm/bridge/synopsys/Kconfig
+++ b/drivers/gpu/drm/bridge/synopsys/Kconfig
@@ -23,3 +23,12 @@ config DRM_DW_HDMI_I2S_AUDIO
help
  Support the I2S Audio interface which is part of the Synopsys
  Designware HDMI block.
+
+config DRM_DW_HDMI_CEC
+   tristate "Synopsis Designware CEC interface"
+   depends on DRM_DW_HDMI
+   select CEC_CORE
+   select CEC_NOTIFIER
+   help
+ Support the CE interface which is part of the Synopsys
+ Designware HDMI block.
diff --git a/drivers/gpu/drm/bridge/synopsys/Makefile 
b/drivers/gpu/drm/bridge/synopsys/Makefile
index 17aa7a65b57e..6fe415903668 100644
--- a/drivers/gpu/drm/bridge/synopsys/Makefile
+++ b/drivers/gpu/drm/bridge/synopsys/Makefile
@@ -3,3 +3,4 @@
 obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
 obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
 obj-$(CONFIG_DRM_DW_HDMI_I2S_AUDIO) += dw-hdmi-i2s-audio.o
+obj-$(CONFIG_DRM_DW_HDMI_CEC) += dw-hdmi-cec.o
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c
new file mode 100644
index ..52c9d93b9602
--- /dev/null
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c
@@ -0,0 +1,326 @@
+/*
+ * Designware HDMI CEC driver
+ *
+ * Copyright (C) 2015-2017 Russell King.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+
+#include "dw-hdmi-cec.h"
+
+enum {
+   HDMI_IH_CEC_STAT0   = 0x0106,
+   HDMI_IH_MUTE_CEC_STAT0  = 0x0186,
+
+   HDMI_CEC_CTRL   = 0x7d00,
+   CEC_CTRL_START  = BIT(0),
+   CEC_CTRL_FRAME_TYP  = 3 << 1,
+   CEC_CTRL_RETRY  = 0 << 1,
+   CEC_CTRL_NORMAL = 1 << 1,
+   CEC_CTRL_IMMED  = 2 << 1,
+
+   HDMI_CEC_STAT   = 0x7d01,
+   CEC_STAT_DONE   = BIT(0),
+   CEC_STAT_EOM= BIT(1),
+   CEC_STAT_NACK   = BIT(2),
+   CEC_STAT_ARBLOST= BIT(3),
+   CEC_STAT_ERROR_INIT = BIT(4),
+   CEC_STAT_ERROR_FOLL = BIT(5),
+   CEC_STAT_WAKEUP = BIT(6),
+
+   HDMI_CEC_MASK   = 0x7d02,
+   HDMI_CEC_POLARITY   = 0x7d03,
+   HDMI_CEC_INT= 0x7d04,
+   HDMI_CEC_ADDR_L = 0x7d05,
+   HDMI_CEC_ADDR_H = 0x7d06,
+   HDMI_CEC_TX_CNT = 0x7d07,
+   HDMI_CEC_RX_CNT = 0x7d08,
+   HDMI_CEC_TX_DATA0   = 0x7d10,
+   HDMI_CEC_RX_DATA0   = 0x7d20,
+   HDMI_CEC_LOCK   = 0x7d30,
+   HDMI_CEC_WKUPCTRL   = 0x7d31,
+};
+
+struct dw_hdmi_cec {
+   struct dw_hdmi *hdmi;
+   const struct dw_hdmi_cec_ops *ops;
+   u32 addresses;
+   struct cec_adapter *adap;
+   struct cec_msg rx_msg;
+   unsigned int tx_status;
+   bool tx_done;
+   bool rx_done;
+   struct cec_notifier *notify;
+   int irq;
+};
+
+static void dw_hdmi_write(struct dw_hdmi_cec *cec, u8 val, int offset)
+{
+   cec->ops->write(cec->hdmi, val, offset);
+}
+
+static u8 dw_hdmi_read(struct dw_hdmi_cec *cec, int offset)
+{
+   return cec->ops->read(cec->hdmi, offset);
+}
+
+static int dw_hdmi_cec_log_addr(struct cec_adapter *adap, u8 logical_addr)
+{
+   struct dw_hdmi_cec *cec = cec_get_drvdata(adap);
+
+   if (logical_addr == CEC_LOG_ADDR_INVALID)
+   cec->addresses = 0;
+   else
+   cec->addresses |= BIT(logical_addr) | BIT(15);
+
+   dw_hdmi_write(cec, cec->addresses & 255, HDMI_CEC_ADDR_L);
+   dw_hdmi_write(cec, cec->addresses >> 8, HDMI_CEC_ADDR_H);
+
+   return 0;
+}
+
+static int dw_hdmi_cec_transmit(struct cec_adapter *adap, u8 attempts,
+   u32 signal_free_time, struct cec_msg *msg)
+{
+   struct dw_hdmi_cec *cec = cec_get_drvdata(adap);
+   unsigned i, ctrl;
+
+   switch (signal_free_time) {
+   case CEC_SIGNAL_FREE_TIME_RETRY:
+   ctrl 

Re: [PATCH] powerpc/asm/cacheflush: Cleanup cacheflush function params

[Christophe LEROY]

Le 20/07/2017 à 08:28, Matt Brown a écrit :

The cacheflush prototypes currently use start and stop values and each
call requires typecasting the address to an unsigned long.
This patch changes the cacheflush prototypes to follow the x86 style of
using a base and size values, with base being a void pointer.

All callers of the cacheflush functions, including drivers, have been
modified to conform to the new prototypes.

The 64 bit cacheflush functions which were implemented in assembly code
(flush_dcache_range, flush_inval_dcache_range) have been translated into
C for readability and coherence.

Signed-off-by: Matt Brown 
---
  arch/powerpc/include/asm/cacheflush.h| 47 +
  arch/powerpc/kernel/misc_64.S| 52 
  arch/powerpc/mm/dma-noncoherent.c| 15 
  arch/powerpc/platforms/512x/mpc512x_shared.c | 10 +++---
  arch/powerpc/platforms/85xx/smp.c|  6 ++--
  arch/powerpc/sysdev/dart_iommu.c |  5 +--
  drivers/ata/pata_bf54x.c |  3 +-
  drivers/char/agp/uninorth-agp.c  |  6 ++--
  drivers/gpu/drm/drm_cache.c  |  3 +-
  drivers/macintosh/smu.c  | 15 
  drivers/mmc/host/bfin_sdh.c  |  3 +-
  drivers/mtd/nand/bf5xx_nand.c|  6 ++--
  drivers/soc/fsl/qbman/dpaa_sys.h |  2 +-
  drivers/soc/fsl/qbman/qman_ccsr.c|  3 +-
  drivers/spi/spi-bfin5xx.c| 10 +++---
  drivers/tty/serial/mpsc.c| 46 
  drivers/usb/musb/blackfin.c  |  6 ++--
  17 files changed, 86 insertions(+), 152 deletions(-)



[...]


diff --git a/arch/powerpc/mm/dma-noncoherent.c 
b/arch/powerpc/mm/dma-noncoherent.c
index 3825284..5fd3171 100644
--- a/arch/powerpc/mm/dma-noncoherent.c
+++ b/arch/powerpc/mm/dma-noncoherent.c
@@ -204,9 +204,9 @@ __dma_alloc_coherent(struct device *dev, size_t size, 
dma_addr_t *handle, gfp_t
 * kernel direct-mapped region for device DMA.
 */
{
-   unsigned long kaddr = (unsigned long)page_address(page);
+   void *kaddr = page_address(page);
memset(page_address(page), 0, size);
-   flush_dcache_range(kaddr, kaddr + size);
+   flush_dcache_range(kaddr, size);
}
  
  	/*

@@ -316,9 +316,6 @@ EXPORT_SYMBOL(__dma_free_coherent);
   */
  void __dma_sync(void *vaddr, size_t size, int direction)
  {
-   unsigned long start = (unsigned long)vaddr;
-   unsigned long end   = start + size;
-
switch (direction) {
case DMA_NONE:
BUG();
@@ -328,15 +325,15 @@ void __dma_sync(void *vaddr, size_t size, int direction)
 * the potential for discarding uncommitted data from the cache
 */
if ((start | end) & (L1_CACHE_BYTES - 1))


How can the above compile when 'start' and 'end' are removed ?
Shouldn't it be replaced by

if ((vaddr | size) & (L1_CACHE_BYTES - 1))


-   flush_dcache_range(start, end);
+   flush_dcache_range(vaddr, size);
else
-   invalidate_dcache_range(start, end);
+   invalidate_dcache_range(vaddr, size);
break;
case DMA_TO_DEVICE: /* writeback only */
-   clean_dcache_range(start, end);
+   clean_dcache_range(vaddr, size);
break;
case DMA_BIDIRECTIONAL: /* writeback and invalidate */
-   flush_dcache_range(start, end);
+   flush_dcache_range(vaddr, size);
break;
}
  }


[...]

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

Re: [PATCH v4 0/3] Add support for the s6e63j0x03 panel on Rinato board

[Hoegeun Kwon]

Dear Thierry,

Could you please check these patches.

Best regards,
Hoegeun


On 07/13/2017 11:20 AM, Hoegeun Kwon wrote:

Hi Andrzej,

Thank you for your review.

The purpose of this patch is add support for s6e63j0x03 AMOLED panel
on the rinato board(Samsung Galaxy Gear 2).

Changes for V4:
- Added Reviewed-by: Andrzej Hajda  (2/3 patch).
- Fixed the style of macro function.

Changes for V3:
- Applied patch 'ARM: dts: exynos: Fix the active of reset gpios from rinato 
dts' (v2 3/4)
- Remove the unnecessary define ('MIN_BRIGHTNESS')
- Removed explicit casting.
- Removed violation of kernel coding style.

Changes for V2:
- Added the interface info in binding document.
- Added Reviewed-by: Andrzej Hajda  (1/3 patch).
- Added Acked-by: Rob Herring  (1/3 patch).
- Fixed the tristate of config from video mode to command mode.
- Fixed the reset gpios from active high to low from rinato dts.
- Fixed a lot of things in panel driver, reflect Andrzej's review.

Best regards,
Hoegeun

Hoegeun Kwon (3):
   dt-bindings: Add support for samsung s6e63j0x03 panel binding
   drm/panel: Add support for s6e63j0x03 panel driver
   ARM: dts: exynos: Remove the display-timing and delay from rinato dts

  .../bindings/display/panel/samsung,s6e63j0x03.txt  |  24 +
  arch/arm/boot/dts/exynos3250-rinato.dts|  22 -
  drivers/gpu/drm/panel/Kconfig  |   7 +
  drivers/gpu/drm/panel/Makefile |   1 +
  drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c   | 532 +
  5 files changed, 564 insertions(+), 22 deletions(-)
  create mode 100644 
Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt
  create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c



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

Re: [PATCH 0/7] drm/exynos: panel mode info propagation

[Inki Dae]

2017년 07월 26일 16:09에 Andrzej Hajda 이(가) 쓴 글:
> On 18.04.2017 14:39, Andrzej Hajda wrote:
>> Hi Inki,
>>
>> This patchset beside cleanup/refactoring patches (01-03) adds code to 
>> propagate
>> info provided by MIPI-DSI panels about its mode of work (video/command mode).
>> The propagation is performed for whole pipeline as every its elements uses 
>> it.
> 
> Gently ping.

Sorry for late. Will review them soon.

Thanks,
Inki Dae

> 
> Regards
> Andrzej
> 
>>
>> Regards
>> Andrzej
>>
>>
>> Andrzej Hajda (7):
>>   drm/exynos/decon5433: use readl_poll_timeout helpers
>>   drm/exynos: use helper to set possible crtcs
>>   drm/exynos/dsi: refactor panel detection logic
>>   drm/exynos: propagate info about command mode from panel
>>   drm/exynos/mic: use mode info stored in CRTC to detect i80 mode
>>   drm/exynos/decon5433: use mode info stored in CRTC to detect i80 mode
>>   dt-bindings: exynos5433-decon: remove i80-if-timings property
>>
>>  .../bindings/display/exynos/exynos5433-decon.txt   |   6 -
>>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c  | 118 ++-
>>  drivers/gpu/drm/exynos/exynos_dp.c |  15 +-
>>  drivers/gpu/drm/exynos/exynos_drm_core.c   |   1 +
>>  drivers/gpu/drm/exynos/exynos_drm_crtc.c   |  21 +-
>>  drivers/gpu/drm/exynos/exynos_drm_crtc.h   |  10 +-
>>  drivers/gpu/drm/exynos/exynos_drm_dpi.c|  12 +-
>>  drivers/gpu/drm/exynos/exynos_drm_drv.h|   1 +
>>  drivers/gpu/drm/exynos/exynos_drm_dsi.c| 219 
>> ++---
>>  drivers/gpu/drm/exynos/exynos_drm_mic.c|  44 +
>>  drivers/gpu/drm/exynos/exynos_drm_vidi.c   |  15 +-
>>  drivers/gpu/drm/exynos/exynos_hdmi.c   |  25 +--
>>  12 files changed, 228 insertions(+), 259 deletions(-)
>>
> 
> 
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101377] Gigabyte R9 380 card fails to load, kernel reports bug

[bugzilla-daemon]

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

--- Comment #9 from j...@dev1ce.com ---
unfortunately copying the firmware did not solve the problem.  the fan noise is
no longer emitted, however the graphics driver still fails to properly load.

could this be an issue with, perhaps, the IOMMU implementation of my
motherboard?  is IOMMU2 support a requirement perhaps?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101961] Serious Sam Fusion hangs system completely

[bugzilla-daemon]

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

--- Comment #9 from Samuel Pitoiset  ---
By the way, do you have some hints about how to reproduce, like which settings,
which steps, etc? Also, what version is exactly, I mean the Steam appid?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101961] Serious Sam Fusion hangs system completely

[bugzilla-daemon]

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

--- Comment #8 from Samuel Pitoiset  ---
Okay, I should be able to reproduce tomorrow, I will let you know.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 0/2] ASoC: hdmi-codec: Allow driver to restrict sample size

[srinivas . kandagatla]

From: Srinivas Kandagatla 

This patch adds option to allow hdmi-codec drivers to restrict
the audio sample size based on the values that are suppored in hardware.

First patch is adding that formats option to hdmi_codec_pdata and
second patch is a fix in adv7511 codec driver which only supports
16 and 24 bit samples. 

Changes since v1:
- Added Review by Jyri
- Updated comment in code suggested by Jyri

Srinivas Kandagatla (2):
  ASoC: hdmi-codec: Allow drivers to restrict sample sizes.
  drm/bridge: adv7511: restrict audio sample sizes

 drivers/gpu/drm/bridge/adv7511/adv7511_audio.c | 2 ++
 include/sound/hdmi-codec.h | 1 +
 sound/soc/codecs/hdmi-codec.c  | 8 +---
 3 files changed, 8 insertions(+), 3 deletions(-)

-- 
2.11.0

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

[PATCH v2 1/2] ASoC: hdmi-codec: Allow drivers to restrict sample sizes.

[srinivas . kandagatla]

From: Srinivas Kandagatla 

Currently hdmi client drivers does have means to limit the
sample sizes that it can only support. Having formats parameter
option would solve this.

This issue was noticed on DB410c board when adv7511 hdmi codec driver
failed to play a 32 bits audio samples, as it does not support them.

Signed-off-by: Srinivas Kandagatla 
Reviewed-by: Jyri Sarha 
---
 include/sound/hdmi-codec.h| 1 +
 sound/soc/codecs/hdmi-codec.c | 8 +---
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/include/sound/hdmi-codec.h b/include/sound/hdmi-codec.h
index 9483c55f871b..89fc4cce5785 100644
--- a/include/sound/hdmi-codec.h
+++ b/include/sound/hdmi-codec.h
@@ -104,6 +104,7 @@ struct hdmi_codec_pdata {
uint i2s:1;
uint spdif:1;
int max_i2s_channels;
+   u64 formats;
void *data;
 };
 
diff --git a/sound/soc/codecs/hdmi-codec.c b/sound/soc/codecs/hdmi-codec.c
index 22ed0dc88f0a..a7b4d6757ff1 100644
--- a/sound/soc/codecs/hdmi-codec.c
+++ b/sound/soc/codecs/hdmi-codec.c
@@ -653,9 +653,8 @@ static const struct snd_soc_dai_ops hdmi_dai_ops = {
  * This list is only for formats allowed on the I2S bus. So there is
  * some formats listed that are not supported by HDMI interface. For
  * instance allowing the 32-bit formats enables 24-precision with CPU
- * DAIs that do not support 24-bit formats. If the extra formats cause
- * problems, we should add the video side driver an option to disable
- * them.
+ * DAIs that do not support 24-bit formats. Driver can either use this
+ * list or specify supported formats in formats field of hdmi_codec_pdata.
  */
 #define I2S_FORMATS(SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S16_BE |\
 SNDRV_PCM_FMTBIT_S20_3LE | SNDRV_PCM_FMTBIT_S20_3BE |\
@@ -780,6 +779,9 @@ static int hdmi_codec_probe(struct platform_device *pdev)
hcp->daidrv[i] = hdmi_i2s_dai;
hcp->daidrv[i].playback.channels_max =
hcd->max_i2s_channels;
+
+   if (hcd->formats)
+   hcp->daidrv[i].playback.formats = hcd->formats;
i++;
}
 
-- 
2.11.0

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

[PATCH v2 2/2] drm/bridge: adv7511: restrict audio sample sizes

[srinivas . kandagatla]

From: Srinivas Kandagatla 

ADV7533 only supports audio samples word width from 16-24 bits.
This patch restricts the audio sample sizes to the supported ones,
so that sound card does not report wrong list of supported hwparms.

Without this patch aplay would fail when playing a 32 bit audio.

Signed-off-by: Srinivas Kandagatla 
---
 drivers/gpu/drm/bridge/adv7511/adv7511_audio.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
index 67469c26bae8..d01d0aa0eef7 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
@@ -214,6 +214,8 @@ static struct hdmi_codec_pdata codec_data = {
.ops = _codec_ops,
.max_i2s_channels = 2,
.i2s = 1,
+   .formats = (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S16_BE |
+   SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S24_BE),
 };
 
 int adv7511_audio_init(struct device *dev, struct adv7511 *adv7511)
-- 
2.11.0

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

[Bug 101787] colours all messed up

[bugzilla-daemon]

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

--- Comment #12 from Julien Isorce  ---
(In reply to 247 from comment #10)
> Created attachment 132816 [details]
> vainfo
> 
> just attached the vainfo result...

Please also attach the output when running vainfo in fedora36-cinnamon.

> the gst command instead results in a
> syntax error...just in case there are no errors in mesa, maybe a hint where
> i could look for help?

What was the syntax error ?

> 
> just in case : updated to latests gstreamer/mesa/kernel but that didn't
> solve my problem, and i tried a fresh installation with fedora 26 cinnamon
> and it's perfectly working, but i don't know if it count since i have
> problems in a gnome environment...

What is the difference between fedora26-cinnamon(OK) and fedora26-gnome(KO) ?
(x11 vs wayland ?)

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101961] Serious Sam Fusion hangs system completely

[bugzilla-daemon]

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

network...@rkmail.ru changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED

--- Comment #7 from network...@rkmail.ru ---
Actually, I may have been wrong about revering 5c1241268b fixes the crash.
After a really long session in the game system froze again. Here are last lines
from the journal:

kernel: gmc_v8_0_process_interrupt: 7 callbacks suppressed
kernel: amdgpu :28:00.0: GPU fault detected: 147 0x4801
kernel: amdgpu :28:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x0550
kernel: amdgpu :28:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x02048001
kernel: amdgpu :28:00.0: VM fault (0x01, vmid 1) at page 89128960, read
from 'TC4' (0x54433400) (72)
kernel: amdgpu :28:00.0: GPU fault detected: 147 0x4801
kernel: amdgpu :28:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x0550
kernel: amdgpu :28:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x02048001
kernel: amdgpu :28:00.0: VM fault (0x01, vmid 1) at page 89128960, read
from 'TC4' (0x54433400) (72)
kernel: amdgpu :28:00.0: GPU fault detected: 147 0x4801
kernel: amdgpu :28:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x0550
kernel: amdgpu :28:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x02048001
kernel: amdgpu :28:00.0: VM fault (0x01, vmid 1) at page 89128960, read
from 'TC4' (0x54433400) (72)

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amdgpu: Make amdgpu_atif_handler static

[Alex Deucher]

On Sun, Jul 30, 2017 at 7:11 AM, Jean Delvare  wrote:
> There are no external users of function amdgpu_atif_handler so it can
> be static.
>
> Signed-off-by: Jean Delvare 
> Cc: Alex Deucher 
> Cc: "Christian König" 

Applied.  thanks!

Alex

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- linux-4.12.orig/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c2017-07-30 
> 13:06:19.949418618 +0200
> +++ linux-4.12/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c 2017-07-30 
> 13:07:14.949120591 +0200
> @@ -289,7 +289,7 @@ static int amdgpu_atif_get_sbios_request
>   * handles it.
>   * Returns NOTIFY code
>   */
> -int amdgpu_atif_handler(struct amdgpu_device *adev,
> +static int amdgpu_atif_handler(struct amdgpu_device *adev,
> struct acpi_bus_event *event)
>  {
> struct amdgpu_atif *atif = >atif;
>
>
> --
> Jean Delvare
> SUSE L3 Support
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amdgpu: Fix amdgpu_pm_acpi_event_handler warning

[Alex Deucher]

On Sun, Jul 30, 2017 at 7:42 AM, Jean Delvare  wrote:
> Include a missing header to get rid of the following warning:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c:65:6: warning: no previous prototype 
> for ‘amdgpu_pm_acpi_event_handler’ [-Wmissing-prototypes]
>  void amdgpu_pm_acpi_event_handler(struct amdgpu_device *adev)
>   ^
>
> Signed-off-by: Jean Delvare 
> Cc: Alex Deucher 
> Cc: "Christian König" 

Applied.  thanks!

Alex

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c |2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_pm.h   |1 +
>  2 files changed, 2 insertions(+), 1 deletion(-)
>
> --- linux-4.12.orig/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c2017-07-30 
> 13:18:54.991917627 +0200
> +++ linux-4.12/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c 2017-07-30 
> 13:26:16.786365654 +0200
> @@ -30,10 +30,10 @@
>  #include 
>  #include 
>  #include "amdgpu.h"
> +#include "amdgpu_pm.h"
>  #include "amd_acpi.h"
>  #include "atom.h"
>
> -extern void amdgpu_pm_acpi_event_handler(struct amdgpu_device *adev);
>  /* Call the ATIF method
>   */
>  /**
> --- linux-4.12.orig/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.h  2017-07-30 
> 13:18:54.991917627 +0200
> +++ linux-4.12/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.h   2017-07-30 
> 13:26:16.787365666 +0200
> @@ -30,6 +30,7 @@ struct cg_flag_name
> const char *name;
>  };
>
> +void amdgpu_pm_acpi_event_handler(struct amdgpu_device *adev);
>  int amdgpu_pm_sysfs_init(struct amdgpu_device *adev);
>  void amdgpu_pm_sysfs_fini(struct amdgpu_device *adev);
>  void amdgpu_pm_print_power_states(struct amdgpu_device *adev);
>
>
> --
> Jean Delvare
> SUSE L3 Support
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amdgpu: Fix dce_v6_0_disable_dce warning

[Alex Deucher]

On Sun, Jul 30, 2017 at 7:26 AM, Jean Delvare  wrote:
> Include a missing header to get rid of the following warning:
>
> drivers/gpu/drm/amd/amdgpu/dce_v6_0.c:521:6: warning: no previous prototype 
> for 'dce_v6_0_disable_dce' [-Wmissing-prototypes]
>  void dce_v6_0_disable_dce(struct amdgpu_device *adev)
>   ^
>
> Signed-off-by: Jean Delvare 
> Cc: Alex Deucher 
> Cc: "Christian König" 

Applied.  thanks!

Alex

> ---
>  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c |1 +
>  1 file changed, 1 insertion(+)
>
> --- linux-4.12.orig/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c   2017-07-30 
> 13:19:50.546603215 +0200
> +++ linux-4.12/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c2017-07-30 
> 13:21:20.083704388 +0200
> @@ -42,6 +42,7 @@
>  #include "dce/dce_6_0_d.h"
>  #include "dce/dce_6_0_sh_mask.h"
>  #include "gca/gfx_7_2_enum.h"
> +#include "dce_v6_0.h"
>  #include "si_enums.h"
>
>  static void dce_v6_0_set_display_funcs(struct amdgpu_device *adev);
>
>
> --
> Jean Delvare
> SUSE L3 Support
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amdgpu: Fix undue fallthroughs in golden registers initialization

[Alex Deucher]

On Sun, Jul 30, 2017 at 9:07 PM, Marek Olšák  wrote:
> Reviewed-by: Marek Olšák 
>
> Marek
>
> On Sun, Jul 30, 2017 at 10:18 AM, Jean Delvare  wrote:
>>
>> As I was staring at the si_init_golden_registers code, I noticed that
>> the Pitcairn initialization silently falls through the Cape Verde
>> initialization, and the Oland initialization falls through the Hainan
>> initialization. However there is no comment stating that this is
>> intentional, and the radeon driver doesn't have any such fallthrough,
>> so I suspect this is not supposed to happen.
>>
>> Signed-off-by: Jean Delvare 
>> Fixes: 62a37553414a ("drm/amdgpu: add si implementation v10")
>> Cc: Ken Wang 
>> Cc: Alex Deucher 
>> Cc: "Marek Olšák" 
>> Cc: "Christian König" 
>> Cc: Flora Cui 

Applied.  thanks!

Alex


>> ---
>> If the fallthroughs are really supposed to happen, comments should be
>> added that say so. Surprisingly it doesn't seem to make any
>> difference on my Oland card.
>>
>>  drivers/gpu/drm/amd/amdgpu/si.c |2 ++
>>  1 file changed, 2 insertions(+)
>>
>> --- linux-4.12.orig/drivers/gpu/drm/amd/amdgpu/si.c 2017-07-30
>> 09:25:46.891083334 +0200
>> +++ linux-4.12/drivers/gpu/drm/amd/amdgpu/si.c  2017-07-30
>> 09:45:24.350188642 +0200
>> @@ -1385,6 +1385,7 @@ static void si_init_golden_registers(str
>> amdgpu_program_register_sequence(adev,
>>  pitcairn_mgcg_cgcg_init,
>>  (const
>> u32)ARRAY_SIZE(pitcairn_mgcg_cgcg_init));
>> +   break;
>> case CHIP_VERDE:
>> amdgpu_program_register_sequence(adev,
>>  verde_golden_registers,
>> @@ -1409,6 +1410,7 @@ static void si_init_golden_registers(str
>> amdgpu_program_register_sequence(adev,
>>  oland_mgcg_cgcg_init,
>>  (const
>> u32)ARRAY_SIZE(oland_mgcg_cgcg_init));
>> +   break;
>> case CHIP_HAINAN:
>> amdgpu_program_register_sequence(adev,
>>  hainan_golden_registers,
>>
>>
>> --
>> Jean Delvare
>> SUSE L3 Support
>
>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/3] selftests: sync: add test that closes the fd before fence signal

[Gustavo Padovan]

2017-07-30 Chris Wilson :

> Quoting Gustavo Padovan (2017-07-29 16:22:17)
> > From: Gustavo Padovan 
> > 
> > We found this bug in the sw_sync so adding a test case to prevent it to
> > happen in the future.
> > 
> > Cc: Shuah Khan 
> > Cc: linux-kselft...@vger.kernel.org
> > Signed-off-by: Gustavo Padovan 
> > 
> > ---
> > To be applied after the TAP13 convertion patches.
> > ---
> >  tools/testing/selftests/sync/sync_fence.c | 23 +++
> >  tools/testing/selftests/sync/sync_test.c  |  1 +
> >  tools/testing/selftests/sync/synctest.h   |  1 +
> >  3 files changed, 25 insertions(+)
> > 
> > diff --git a/tools/testing/selftests/sync/sync_fence.c 
> > b/tools/testing/selftests/sync/sync_fence.c
> > index 13f1752..70cfa61 100644
> > --- a/tools/testing/selftests/sync/sync_fence.c
> > +++ b/tools/testing/selftests/sync/sync_fence.c
> > @@ -29,6 +29,29 @@
> >  #include "sw_sync.h"
> >  #include "synctest.h"
> >  
> > +int test_close_fence_fd_before_inc(void)
> > +{
> > +   int fence, valid, ret;
> > +   int timeline = sw_sync_timeline_create();
> > +
> > +   valid = sw_sync_timeline_is_valid(timeline);
> > +   ASSERT(valid, "Failure allocating timeline\n");
> > +
> > +   fence = sw_sync_fence_create(timeline, "allocFence", 1);
> > +   valid = sw_sync_fence_is_valid(fence);
> > +   ASSERT(valid, "Failure allocating fence\n");
> > +
> 
> /*
>  * We want the destroy + inc to run within the same RCU grace period so
>  * that the zombie fence still exists on the timeline.
>  */
> 
> > +   sw_sync_fence_destroy(fence);
> 
> I think this doesn't exercise the bug you found as we should be entering
> the timeline_inc loop with fence.refcount==0 rather than the refcount
> going to zero within the loop.
> 
> To achieve that we need to find a callback that does unreference a
> dma-fence and chain those together so that it frees a sw_sync from the
> same timeline.

Indeed. Without the internal callback this test is a bit useless. We
could test this under drm atomic tests on IGT. Particulary, I hit it
playing with tests for v4l2 fences.

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

[Bug 101969] Massive graphics corruption with World of Warcraft

[bugzilla-daemon]

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

--- Comment #4 from Chris Rankin  ---
(In reply to Marek Olšák from comment #2)
> Can you please test this patch?

No, it doesn't work for me either.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] dma-buf/sync_file: document flags field

[Gustavo Padovan]

From: Gustavo Padovan 

Documentation for it was missing.

Signed-off-by: Gustavo Padovan 
---
 include/linux/sync_file.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/linux/sync_file.h b/include/linux/sync_file.h
index 0ad87c4..790ca02 100644
--- a/include/linux/sync_file.h
+++ b/include/linux/sync_file.h
@@ -25,8 +25,12 @@
  * @file:  file representing this fence
  * @sync_file_list:membership in global file list
  * @wq:wait queue for fence signaling
+ * @flags: flags for the sync_file
  * @fence: fence with the fences in the sync_file
  * @cb:fence callback information
+ *
+ * flags:
+ * POLL_ENABLED: whether userspace is currently poll()'ing or not
  */
 struct sync_file {
struct file *file;
-- 
2.9.4

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

Re: [PATCH 2/3] dma-buf/sw_sync: clean up list before signaling the fence

[Gustavo Padovan]

2017-07-30 Chris Wilson :

> Quoting Gustavo Padovan (2017-07-29 16:22:16)
> > From: Gustavo Padovan 
> > 
> > If userspace already dropped its own reference by closing the sw_sync
> > fence fd we might end up in a deadlock where
> > dma_fence_is_signaled_locked() will trigger the release of the fence and
> > thus try to hold the lock to remove the fence from the list.
> > 
> > dma_fence_is_signaled_locked() tries to release/free the fence and hold
> > the lock in the process.
> > 
> > We fix that by changing the order operation and clean up the list and
> > rb-tree first.
> > 
> > v2: Drop the fence get/put dance and manipulate the list first (Chris 
> > Wilson)
> > 
> > Cc: Chris Wilson 
> > Signed-off-by: Gustavo Padovan 
> Reviewed-by: Chris Wilson 

Thanks for reviewing. Pushed to drm-misc-next.

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

Re: [PATCH 1/3] dma-buf/sw_sync: move timeline_fence_ops around

[Gustavo Padovan]

2017-07-30 Chris Wilson :

> Quoting Gustavo Padovan (2017-07-29 16:22:15)
> > From: Gustavo Padovan 
> > 
> > We are going to use timeline_fence_signaled() in a internal function in
> > the next commit.
> > 
> > Cc: Chris Wilson 
> > Signed-off-by: Gustavo Padovan 
> 
> Purely mechanical,
> Reviewed-by: Chris Wilson 

Thanks for reviewing. Pushed to drm-misc-next.

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

[PATCH 1/4] drm: Add GEM backed framebuffer library

[Noralf Trønnes]

This library provides helpers for drivers that don't subclass
drm_framebuffer and are backed by drm_gem_object. The code is
taken from drm_fb_cma_helper.

Signed-off-by: Noralf Trønnes 
---
 Documentation/gpu/drm-kms-helpers.rst|   9 +
 drivers/gpu/drm/Makefile |   2 +-
 drivers/gpu/drm/drm_gem_framebuffer_helper.c | 252 +++
 include/drm/drm_framebuffer.h|   4 +
 include/drm/drm_gem_framebuffer_helper.h |  35 
 5 files changed, 301 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/drm_gem_framebuffer_helper.c
 create mode 100644 include/drm/drm_gem_framebuffer_helper.h

diff --git a/Documentation/gpu/drm-kms-helpers.rst 
b/Documentation/gpu/drm-kms-helpers.rst
index 7c5e254..13dd237 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -296,3 +296,12 @@ Auxiliary Modeset Helpers
 
 .. kernel-doc:: drivers/gpu/drm/drm_modeset_helper.c
:export:
+
+Framebuffer GEM Helper Reference
+
+
+.. kernel-doc:: drivers/gpu/drm/drm_gem_framebuffer_helper.c
+   :doc: overview
+
+.. kernel-doc:: drivers/gpu/drm/drm_gem_framebuffer_helper.c
+   :export:
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 24a066e..a8acc19 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -33,7 +33,7 @@ drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o 
drm_probe_helper.o \
drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
drm_kms_helper_common.o drm_dp_dual_mode_helper.o \
drm_simple_kms_helper.o drm_modeset_helper.o \
-   drm_scdc_helper.o
+   drm_scdc_helper.o drm_gem_framebuffer_helper.o
 
 drm_kms_helper-$(CONFIG_DRM_PANEL_BRIDGE) += bridge/panel.o
 drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c 
b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
new file mode 100644
index 000..41a506c
--- /dev/null
+++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
@@ -0,0 +1,252 @@
+/*
+ * drm gem framebuffer helper functions
+ *
+ * Copyright (C) 2017 Noralf Trønnes
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * DOC: overview
+ *
+ * This library provides helpers for drivers that don't subclass
+ * _framebuffer and are backed by _gem_object.
+ */
+
+/**
+ * drm_gem_fb_get_obj() - Get GEM object for framebuffer
+ * @fb: The framebuffer
+ * @plane: Which plane
+ *
+ * Returns the GEM object for given framebuffer.
+ */
+struct drm_gem_object *drm_gem_fb_get_obj(struct drm_framebuffer *fb,
+ unsigned int plane)
+{
+   if (plane >= 4)
+   return NULL;
+
+   return fb->obj[plane];
+}
+EXPORT_SYMBOL_GPL(drm_gem_fb_get_obj);
+
+/**
+ * drm_gem_fb_alloc - Allocate GEM backed framebuffer
+ * @dev: DRM device
+ * @mode_cmd: metadata from the userspace fb creation request
+ * @obj: GEM object(s) backing the framebuffer
+ * @num_planes: Number of planes
+ * @funcs: vtable to be used for the new framebuffer object
+ *
+ * Returns:
+ * Allocated struct drm_framebuffer * or error encoded pointer.
+ */
+struct drm_framebuffer *
+drm_gem_fb_alloc(struct drm_device *dev,
+const struct drm_mode_fb_cmd2 *mode_cmd,
+struct drm_gem_object **obj, unsigned int num_planes,
+const struct drm_framebuffer_funcs *funcs)
+{
+   struct drm_framebuffer *fb;
+   int ret, i;
+
+   fb = kzalloc(sizeof(*fb), GFP_KERNEL);
+   if (!fb)
+   return ERR_PTR(-ENOMEM);
+
+   drm_helper_mode_fill_fb_struct(dev, fb, mode_cmd);
+
+   for (i = 0; i < num_planes; i++)
+   fb->obj[i] = obj[i];
+
+   ret = drm_framebuffer_init(dev, fb, funcs);
+   if (ret) {
+   DRM_DEV_ERROR(dev->dev, "Failed to init framebuffer: %d\n",
+ ret);
+   kfree(fb);
+   return ERR_PTR(ret);
+   }
+
+   return fb;
+}
+EXPORT_SYMBOL(drm_gem_fb_alloc);
+
+/**
+ * drm_gem_fb_destroy - Free GEM backed framebuffer
+ * @fb: DRM framebuffer
+ *
+ * Frees a GEM backed framebuffer with it's backing buffer(s) and the structure
+ * itself. Drivers can use this as their _framebuffer_funcs->destroy
+ * callback.
+ */
+void drm_gem_fb_destroy(struct drm_framebuffer *fb)
+{
+   int i;
+
+   for (i = 0; i < 4; i++) {
+   if (fb->obj[i])
+   drm_gem_object_put_unlocked(fb->obj[i]);
+   }
+
+   

[PATCH 4/4] drm/fb-cma-helper: Remove drm_framebuffer_funcs helpers

[Noralf Trønnes]

No users left, so remove drm_fb_cma_destroy and
drm_fb_cma_create_handle.

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm_fb_cma_helper.c | 13 -
 include/drm/drm_fb_cma_helper.h |  4 
 2 files changed, 17 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c
index d0c0110..e0ba4bf 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -80,19 +80,6 @@ static inline struct drm_fbdev_cma *to_fbdev_cma(struct 
drm_fb_helper *helper)
return container_of(helper, struct drm_fbdev_cma, fb_helper);
 }
 
-void drm_fb_cma_destroy(struct drm_framebuffer *fb)
-{
-   drm_gem_fb_destroy(fb);
-}
-EXPORT_SYMBOL(drm_fb_cma_destroy);
-
-int drm_fb_cma_create_handle(struct drm_framebuffer *fb,
-   struct drm_file *file_priv, unsigned int *handle)
-{
-   return drm_gem_fb_create_handle(fb, file_priv, handle);
-}
-EXPORT_SYMBOL(drm_fb_cma_create_handle);
-
 /**
  * drm_fb_cma_create_with_funcs() - helper function for the
  *  _mode_config_funcs.fb_create
diff --git a/include/drm/drm_fb_cma_helper.h b/include/drm/drm_fb_cma_helper.h
index a323781..ebb4355 100644
--- a/include/drm/drm_fb_cma_helper.h
+++ b/include/drm/drm_fb_cma_helper.h
@@ -28,10 +28,6 @@ void drm_fbdev_cma_set_suspend(struct drm_fbdev_cma 
*fbdev_cma, bool state);
 void drm_fbdev_cma_set_suspend_unlocked(struct drm_fbdev_cma *fbdev_cma,
bool state);
 
-void drm_fb_cma_destroy(struct drm_framebuffer *fb);
-int drm_fb_cma_create_handle(struct drm_framebuffer *fb,
-   struct drm_file *file_priv, unsigned int *handle);
-
 struct drm_framebuffer *drm_fb_cma_create_with_funcs(struct drm_device *dev,
struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd,
const struct drm_framebuffer_funcs *funcs);
-- 
2.7.4

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

[PATCH 3/4] drm/tinydrm: Use drm_gem_framebuffer_helper

[Noralf Trønnes]

Use drm_gem_framebuffer_helper directly instead of the cma
library wrappers.

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 3 ++-
 drivers/gpu/drm/tinydrm/mipi-dbi.c  | 5 +++--
 drivers/gpu/drm/tinydrm/repaper.c   | 5 +++--
 3 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c 
b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
index 551709e..1a8a57c 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -128,7 +129,7 @@ tinydrm_fb_create(struct drm_device *drm, struct drm_file 
*file_priv,
 {
struct tinydrm_device *tdev = drm->dev_private;
 
-   return drm_fb_cma_create_with_funcs(drm, file_priv, mode_cmd,
+   return drm_gem_fb_create_with_funcs(drm, file_priv, mode_cmd,
tdev->fb_funcs);
 }
 
diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c 
b/drivers/gpu/drm/tinydrm/mipi-dbi.c
index c83eeb7..466fab7 100644
--- a/drivers/gpu/drm/tinydrm/mipi-dbi.c
+++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c
@@ -9,6 +9,7 @@
  * (at your option) any later version.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -253,8 +254,8 @@ static int mipi_dbi_fb_dirty(struct drm_framebuffer *fb,
 }
 
 static const struct drm_framebuffer_funcs mipi_dbi_fb_funcs = {
-   .destroy= drm_fb_cma_destroy,
-   .create_handle  = drm_fb_cma_create_handle,
+   .destroy= drm_gem_fb_destroy,
+   .create_handle  = drm_gem_fb_create_handle,
.dirty  = mipi_dbi_fb_dirty,
 };
 
diff --git a/drivers/gpu/drm/tinydrm/repaper.c 
b/drivers/gpu/drm/tinydrm/repaper.c
index 3343d3f..bdbc1c7 100644
--- a/drivers/gpu/drm/tinydrm/repaper.c
+++ b/drivers/gpu/drm/tinydrm/repaper.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 
@@ -614,8 +615,8 @@ static int repaper_fb_dirty(struct drm_framebuffer *fb,
 }
 
 static const struct drm_framebuffer_funcs repaper_fb_funcs = {
-   .destroy= drm_fb_cma_destroy,
-   .create_handle  = drm_fb_cma_create_handle,
+   .destroy= drm_gem_fb_destroy,
+   .create_handle  = drm_gem_fb_create_handle,
.dirty  = repaper_fb_dirty,
 };
 
-- 
2.7.4

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

[PATCH 2/4] drm/fb-cma-helper: Use drm_gem_framebuffer_helper

[Noralf Trønnes]

Use the new drm_gem_framebuffer_helper who's code was copied
from this helper.

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm_fb_cma_helper.c | 172 +++-
 1 file changed, 30 insertions(+), 142 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c
index ade319d..d0c0110 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -18,27 +18,17 @@
  */
 
 #include 
-#include 
-#include 
 #include 
-#include 
+#include 
 #include 
+#include 
 #include 
-#include 
-#include 
 #include 
-#include 
 
 #define DEFAULT_FBDEFIO_DELAY_MS 50
 
-struct drm_fb_cma {
-   struct drm_framebuffer  fb;
-   struct drm_gem_cma_object   *obj[4];
-};
-
 struct drm_fbdev_cma {
struct drm_fb_helperfb_helper;
-   struct drm_fb_cma   *fb;
const struct drm_framebuffer_funcs *fb_funcs;
 };
 
@@ -90,69 +80,19 @@ static inline struct drm_fbdev_cma *to_fbdev_cma(struct 
drm_fb_helper *helper)
return container_of(helper, struct drm_fbdev_cma, fb_helper);
 }
 
-static inline struct drm_fb_cma *to_fb_cma(struct drm_framebuffer *fb)
-{
-   return container_of(fb, struct drm_fb_cma, fb);
-}
-
 void drm_fb_cma_destroy(struct drm_framebuffer *fb)
 {
-   struct drm_fb_cma *fb_cma = to_fb_cma(fb);
-   int i;
-
-   for (i = 0; i < 4; i++) {
-   if (fb_cma->obj[i])
-   drm_gem_object_put_unlocked(_cma->obj[i]->base);
-   }
-
-   drm_framebuffer_cleanup(fb);
-   kfree(fb_cma);
+   drm_gem_fb_destroy(fb);
 }
 EXPORT_SYMBOL(drm_fb_cma_destroy);
 
 int drm_fb_cma_create_handle(struct drm_framebuffer *fb,
struct drm_file *file_priv, unsigned int *handle)
 {
-   struct drm_fb_cma *fb_cma = to_fb_cma(fb);
-
-   return drm_gem_handle_create(file_priv,
-   _cma->obj[0]->base, handle);
+   return drm_gem_fb_create_handle(fb, file_priv, handle);
 }
 EXPORT_SYMBOL(drm_fb_cma_create_handle);
 
-static struct drm_framebuffer_funcs drm_fb_cma_funcs = {
-   .destroy= drm_fb_cma_destroy,
-   .create_handle  = drm_fb_cma_create_handle,
-};
-
-static struct drm_fb_cma *drm_fb_cma_alloc(struct drm_device *dev,
-   const struct drm_mode_fb_cmd2 *mode_cmd,
-   struct drm_gem_cma_object **obj,
-   unsigned int num_planes, const struct drm_framebuffer_funcs *funcs)
-{
-   struct drm_fb_cma *fb_cma;
-   int ret;
-   int i;
-
-   fb_cma = kzalloc(sizeof(*fb_cma), GFP_KERNEL);
-   if (!fb_cma)
-   return ERR_PTR(-ENOMEM);
-
-   drm_helper_mode_fill_fb_struct(dev, _cma->fb, mode_cmd);
-
-   for (i = 0; i < num_planes; i++)
-   fb_cma->obj[i] = obj[i];
-
-   ret = drm_framebuffer_init(dev, _cma->fb, funcs);
-   if (ret) {
-   dev_err(dev->dev, "Failed to initialize framebuffer: %d\n", 
ret);
-   kfree(fb_cma);
-   return ERR_PTR(ret);
-   }
-
-   return fb_cma;
-}
-
 /**
  * drm_fb_cma_create_with_funcs() - helper function for the
  *  _mode_config_funcs.fb_create
@@ -170,53 +110,7 @@ struct drm_framebuffer 
*drm_fb_cma_create_with_funcs(struct drm_device *dev,
struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd,
const struct drm_framebuffer_funcs *funcs)
 {
-   const struct drm_format_info *info;
-   struct drm_fb_cma *fb_cma;
-   struct drm_gem_cma_object *objs[4];
-   struct drm_gem_object *obj;
-   int ret;
-   int i;
-
-   info = drm_get_format_info(dev, mode_cmd);
-   if (!info)
-   return ERR_PTR(-EINVAL);
-
-   for (i = 0; i < info->num_planes; i++) {
-   unsigned int width = mode_cmd->width / (i ? info->hsub : 1);
-   unsigned int height = mode_cmd->height / (i ? info->vsub : 1);
-   unsigned int min_size;
-
-   obj = drm_gem_object_lookup(file_priv, mode_cmd->handles[i]);
-   if (!obj) {
-   dev_err(dev->dev, "Failed to lookup GEM object\n");
-   ret = -ENOENT;
-   goto err_gem_object_put;
-   }
-
-   min_size = (height - 1) * mode_cmd->pitches[i]
-+ width * info->cpp[i]
-+ mode_cmd->offsets[i];
-
-   if (obj->size < min_size) {
-   drm_gem_object_put_unlocked(obj);
-   ret = -EINVAL;
-   goto err_gem_object_put;
-   }
-   objs[i] = to_drm_gem_cma_obj(obj);
-   }
-
-   fb_cma = drm_fb_cma_alloc(dev, mode_cmd, objs, i, funcs);
-   if (IS_ERR(fb_cma)) {
-   ret = PTR_ERR(fb_cma);
-   goto err_gem_object_put;
-   }
-
-   return _cma->fb;
-
-err_gem_object_put:
-   for (i--; i >= 0; i--)
-   

[PATCH 0/4] drm: Add GEM backed framebuffer library

[Noralf Trønnes]

This adds helpers for drivers that don't subclass drm_framebuffer and
are backed by drm_gem_object(s). drm_fb_cma_helper is converted to use
the helpers.

This patchset is part of a process to add a shmem gem library like the
cma library. The common parts between the two goes into core or helpers.

I haven't pushed the helpers all the way out to the cma using drivers.
This project has fanned out enough already.

Noralf.

Noralf Trønnes (4):
  drm: Add GEM backed framebuffer library
  drm/fb-cma-helper: Use drm_gem_framebuffer_helper
  drm/tinydrm: Use drm_gem_framebuffer_helper
  drm/fb-cma-helper: Remove drm_framebuffer_funcs helpers

 Documentation/gpu/drm-kms-helpers.rst|   9 +
 drivers/gpu/drm/Makefile |   2 +-
 drivers/gpu/drm/drm_fb_cma_helper.c  | 181 +++
 drivers/gpu/drm/drm_gem_framebuffer_helper.c | 252 +++
 drivers/gpu/drm/tinydrm/core/tinydrm-core.c  |   3 +-
 drivers/gpu/drm/tinydrm/mipi-dbi.c   |   5 +-
 drivers/gpu/drm/tinydrm/repaper.c|   5 +-
 include/drm/drm_fb_cma_helper.h  |   4 -
 include/drm/drm_framebuffer.h|   4 +
 include/drm/drm_gem_framebuffer_helper.h |  35 
 10 files changed, 337 insertions(+), 163 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_gem_framebuffer_helper.c
 create mode 100644 include/drm/drm_gem_framebuffer_helper.h

-- 
2.7.4

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

[Bug 101988] blackscreen after modprobe amdgpu on R9M370X mac edition

[bugzilla-daemon]

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

Alex Deucher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTOURBUG

--- Comment #2 from Alex Deucher  ---
I don't see any problems with the driver load.  The display switching is
handled by a proprietary mechanism independent of the GPU driver on macs.  I'm
not sure what the status of that support is.  I think your problem is likely
related to that.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[maintainer-tools PATCH v2 1/2] dim: Add apply and push shorthands for current branch

[Thierry Reding]

From: Thierry Reding 

The new apply and push commands are shorthands for applying patches to
and pushing the current branch, respectively.

v2: use git symbolic-ref to find current branch (Daniel Vetter)

Signed-off-by: Thierry Reding 
---
 dim | 18 ++
 dim.rst |  8 
 2 files changed, 26 insertions(+)

diff --git a/dim b/dim
index c0cbe352b165..1422b35e2471 100755
--- a/dim
+++ b/dim
@@ -326,6 +326,11 @@ function git_fetch_helper # remote
fi
 }
 
+function git_current_branch
+{
+   git symbolic-ref -q --short HEAD
+}
+
 function git_is_current_branch # branch
 {
git branch --list $1 | grep -q '\*'
@@ -739,6 +744,11 @@ function dim_push_fixes
dim_push_branch drm-intel-fixes "$@"
 }
 
+function dim_push
+{
+   dim_push_branch $(git_current_branch) "$@"
+}
+
 # ensure we're on branch $1, and apply patches. the rest of the arguments are
 # passed to git am.
 dim_alias_ab=apply-branch
@@ -930,6 +940,14 @@ function dim_apply_next_fixes
dim_apply_branch drm-intel-next-fixes "$@"
 }
 
+# apply patch to current branch, the rest of the arguments are passed to
+# git am
+dim_alias_am=apply
+function dim_apply
+{
+   dim_apply_branch $(git_current_branch) "$@"
+}
+
 function commit_list_references
 {
local commit remote log
diff --git a/dim.rst b/dim.rst
index c004c30ada17..fa9b587d73bb 100644
--- a/dim.rst
+++ b/dim.rst
@@ -198,6 +198,10 @@ apply-queued [*git am arguments*]
 **apply-branch** shorthands for *drm-intel-fixes*, *drm-intel-next-fixes*, and
 *drm-intel-next-queued* branches respectively.
 
+apply [*git am arguments*]
+--
+**apply-branch** shorthand for the current branch.
+
 extract-tags *branch* [*git-rangeish*]
 --
 This extracts various tags (e.g. Reviewed-by:) from emails and applies them to 
the
@@ -232,6 +236,10 @@ push-queued [*git push arguments*]
 **push-branch** shorthands for *drm-intel-fixes*, *drm-intel-next-fixes*, and
 *drm-intel-next-queued* branches respectively.
 
+push [*git push arguments*]
+---
+**push** shorthand for the current branch.
+
 rebuild-tip
 ---
 Rebuild and push the integration tree.
-- 
2.13.3

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

[maintainer-tools PATCH 2/2] dim: Simplify test for current branch

[Thierry Reding]

From: Thierry Reding 

Instead of listing branches and grepping for the current branch, simply
read the name of the current branch and compare.

Suggested-by: Daniel Vetter 
Signed-off-by: Thierry Reding 
---
 dim | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/dim b/dim
index 1422b35e2471..ebb1da05662d 100755
--- a/dim
+++ b/dim
@@ -333,7 +333,7 @@ function git_current_branch
 
 function git_is_current_branch # branch
 {
-   git branch --list $1 | grep -q '\*'
+   test "$(git_current_branch)" = "$1"
 }
 
 function git_branch_exists # branch
-- 
2.13.3

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

RE: [PATCH] dma-buf: fix reservation_object_wait_timeout_rcu to wait correctly v2

[Deucher, Alexander]

> -Original Message-
> From: Christian König [mailto:deathsim...@vodafone.de]
> Sent: Monday, July 31, 2017 10:13 AM
> To: linux-me...@vger.kernel.org; dri-devel@lists.freedesktop.org; linaro-
> mm-...@lists.linaro.org; Zhou, David(ChunMing); Deucher, Alexander
> Subject: Re: [PATCH] dma-buf: fix reservation_object_wait_timeout_rcu to
> wait correctly v2
> 
> Ping, what do you guys think of that?

Seems reasonable to me.
Reviewed-by: Alex Deucher 

> 
> Am 25.07.2017 um 15:35 schrieb Christian König:
> > From: Christian König 
> >
> > With hardware resets in mind it is possible that all shared fences are
> > signaled, but the exlusive isn't. Fix waiting for everything in this 
> > situation.
> >
> > v2: make sure we always wait for the exclusive fence
> >
> > Signed-off-by: Christian König 
> > ---
> >   drivers/dma-buf/reservation.c | 33 +++--
> >   1 file changed, 15 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
> > index 393817e..9d4316d 100644
> > --- a/drivers/dma-buf/reservation.c
> > +++ b/drivers/dma-buf/reservation.c
> > @@ -373,12 +373,25 @@ long reservation_object_wait_timeout_rcu(struct
> reservation_object *obj,
> > long ret = timeout ? timeout : 1;
> >
> >   retry:
> > -   fence = NULL;
> > shared_count = 0;
> > seq = read_seqcount_begin(>seq);
> > rcu_read_lock();
> >
> > -   if (wait_all) {
> > +   fence = rcu_dereference(obj->fence_excl);
> > +   if (fence && !test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, 
> >flags)) {
> > +   if (!dma_fence_get_rcu(fence))
> > +   goto unlock_retry;
> > +
> > +   if (dma_fence_is_signaled(fence)) {
> > +   dma_fence_put(fence);
> > +   fence = NULL;
> > +   }
> > +
> > +   } else {
> > +   fence = NULL;
> > +   }
> > +
> > +   if (!fence && wait_all) {
> > struct reservation_object_list *fobj =
> > rcu_dereference(obj-
> >fence);
> >
> > @@ -405,22 +418,6 @@ long reservation_object_wait_timeout_rcu(struct
> reservation_object *obj,
> > }
> > }
> >
> > -   if (!shared_count) {
> > -   struct dma_fence *fence_excl = rcu_dereference(obj-
> >fence_excl);
> > -
> > -   if (fence_excl &&
> > -   !test_bit(DMA_FENCE_FLAG_SIGNALED_BIT,
> > - _excl->flags)) {
> > -   if (!dma_fence_get_rcu(fence_excl))
> > -   goto unlock_retry;
> > -
> > -   if (dma_fence_is_signaled(fence_excl))
> > -   dma_fence_put(fence_excl);
> > -   else
> > -   fence = fence_excl;
> > -   }
> > -   }
> > -
> > rcu_read_unlock();
> > if (fence) {
> > if (read_seqcount_retry(>seq, seq)) {
> 

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

[Bug 101988] blackscreen after modprobe amdgpu on R9M370X mac edition

[bugzilla-daemon]

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

--- Comment #1 from newin...@gmail.com ---
Created attachment 133155
  --> https://bugs.freedesktop.org/attachment.cgi?id=133155=edit
My kernel .config

note that I disabled the intel driver and the runtime gpu switch despite the
fact that 2015 MBP have an internal intel GPU but this bug is also reproducible
with it.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101988] blackscreen after modprobe amdgpu on R9M370X mac edition

[bugzilla-daemon]

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

Bug ID: 101988
   Summary: blackscreen after modprobe amdgpu on R9M370X mac
edition
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: blocker
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: newin...@gmail.com

Created attachment 133154
  --> https://bugs.freedesktop.org/attachment.cgi?id=133154=edit
dmesg after `modprobe amdgpu` and getting blackscreen

I don't know if this is specific to R9M370X - mac edition but I couldn't
reproduce it on other AMD PC I have.

This is fairly simple to reproduce, I just have to mount the amdgpu and I get a
black screen on my main screen and my main screen only (my second screen is
fine)

I don't have this problem using radeon with the exact same kernel config.
dmesg is saying everything is fine and X11 log is irrelevant because it happen
_before_ startx.
I am using Linux 4.12.4-gentoo.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH RESEND] fbdev: omapfb: remove unused variable

[Bartlomiej Zolnierkiewicz]

On Wednesday, July 26, 2017 04:27:30 PM Bartlomiej Zolnierkiewicz wrote:
> 
> Hi,
> 
> On Wednesday, July 26, 2017 03:57:55 PM Arnd Bergmann wrote:
> > Removing the default display name left a harmless warning:
> > 
> > fbdev/omap2/omapfb/dss/core.c: In function 'omap_dss_probe':
> > fbdev/omap2/omapfb/dss/core.c:196:30: error: unused variable 'pdata' 
> > [-Werror=unused-variable]
> > 
> > This removes the now-unused variable as well.
> > 
> > Fixes: 278cba7eaf54 ("drm: omapdrm: Remove unused default display name 
> > support")
> > Signed-off-by: Arnd Bergmann 
> > Reviewed-by: Laurent Pinchart 
> > ---
> > Originally submitted on June 9, no reply other than the Reviewed-by tag.
> > The patch is still needed
> 
> It is not lost and will be queued for 4.13 fbdev fixes pull request.
> 
> [ The guilty commit went through DRM tree and pulling it into fbdev
>   tree just to fix the warning was not feasible.. ]

Patch queued for 4.13, thanks. 

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

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

[Bug 101987] Loud fan and maximum GPU fan speed

[bugzilla-daemon]

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

--- Comment #1 from damian.szymanski...@gmail.com ---
Created attachment 133153
  --> https://bugs.freedesktop.org/attachment.cgi?id=133153=edit
log from inxi -fx

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101987] Loud fan and maximum GPU fan speed

[bugzilla-daemon]

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

Bug ID: 101987
   Summary: Loud fan and maximum GPU fan speed
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: damian.szymanski...@gmail.com

Created attachment 133152
  --> https://bugs.freedesktop.org/attachment.cgi?id=133152=edit
hw-info detalis log

Hi.

Sorry for all mistake but Im newbie ans sorry for my poor english.

I have Radeon HD 5850 and I think something is wrong with him. So even with
minimal GPU load, the fan seems to be spinning up to maximum speed, and the fan
itself does not mercilessly make a lot of noise but only on open source driver
with Mesa. On old legacy fglrx driver all is fine, same as on Windows OS. So I
think worth to report this issue.

For explain.

>From last time I still use AMD Catalyst driver, because I have this issues with
open source driver. My Linux distro Mageia 5 still provide fglrx driver, so I
still use it but now they release Mageia 6 and old Mageia 5 is supported only
for next 3 months. So I need to upgrade or swith distro.

Trying few times install on second partitions other Linux distros like Ubuntu
16.04 and 17.04 and Mageia 6 and OpenMandriva LX3 but with this all distro I
have still the same issue - noisy gpu fan and almost 100% speed on even low gpu
load. So only old Mageia 5 with fglrx or Windows 7 OS can get me silence when I
try watch movie, browse internet or playing games.

For example, when I start game (e.g free) Dota 2 on Mageia 5 with fglrx, and
play it my GPU is silence and the fan is barely audible.
But when I boot to other Linux with open source driver with mesa like
Ubuntu/Mageia6/OpenMandriva and just start game, even in dota2 main menu I hear
the fan spin faster, and faster and faster causing a lot of noise.
This is on all games and movies in vlc, smplayer or mpv, even on
chromium/chrome or firefox.

Trying various mesa version and few version of kernel. Still the same.

So if on Linux with fglrx is all fine and if on Windows 7 all is fine and only
with Linux with Radeon+Mesa have issue, so it is a bug?

Sorry guys, Im newbie and I don't know what I should doing with. Bug? Not a
bug? Any solution or fix? Or maybe should I get more info?

Help :)

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/6] drm/i915: Add render decompression support

[Daniel Stone]

Hi,

On 26 July 2017 at 19:07, Ben Widawsky  wrote:
> Due to hardware limitations we require that the main surface and
> the AUX surface (CCS) be part of the same bo. The hardware also
> makes life hard by not allowing you to provide separate x/y offsets
> for the main and AUX surfaces (excpet with NV12), so finding suitable
> offsets for both requires a bit of work. Assuming we still want keep
> playing tricks with the offsets. I've just gone with a dumb "search
> backward for suitable offsets" approach, which is far from optimal,
>  but it works.
>
>  Also not all planes will be capable of scanning out 
> compressed surfaces,
>  and eg. 90/270 degree rotation is not supported in 
> combination with
>  decompression either.
>
>  This patch may contain work from at least the following 
> people:
>  * Vandana Kannan 
>  * Daniel Vetter 
>  * Ben Widawsky 
>
> v2: Deal with display workarounds 0390, 0531, 1125 (Paulo)
> v3: Pretend CCS tiles are regular 128 byte wide Y tiles (Jason)
> Put the AUX register defines to the correct place
> Fix up the slightly bogus rotation check
> v4: Use I915_WRITE_FW() due to plane update locking changes
> s/return -EINVAL/goto err/ in intel_framebuffer_init()
> Eliminate a bunch hardcoded numbers in CCS code
>
> v5: (By Ben)
> conflict resolution +
> -   res_blocks += fixed_16_16_to_u32_round_up(y_tile_minimum);
> +   res_blocks += fixed16_to_u32_round_up(y_tile_minimum);

':set paste' is your friend :P

Cheers,
Daniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/6] drm/i915: Implement .get_format_info() hook for CCS

[Daniel Stone]

Hi Ben,

On 26 July 2017 at 19:07, Ben Widawsky  wrote:
> v2: Drop the 'dev' argument from the hook
> v3: Include the description of the CCS surface layout

This went missing. Vidya's patch has it though.

> +static const struct drm_format_info ccs_formats[] = {
> +   { .format = DRM_FORMAT_XRGB, .depth = 24, .num_planes = 2, .cpp = 
> { 4, 1, }, .hsub = 16, .vsub = 8, },
> +   { .format = DRM_FORMAT_XBGR, .depth = 24, .num_planes = 2, .cpp = 
> { 4, 1, }, .hsub = 16, .vsub = 8, },
> +   { .format = DRM_FORMAT_ARGB, .depth = 32, .num_planes = 2, .cpp = 
> { 4, 1, }, .hsub = 16, .vsub = 8, },
> +   { .format = DRM_FORMAT_ABGR, .depth = 32, .num_planes = 2, .cpp = 
> { 4, 1, }, .hsub = 16, .vsub = 8, },

Mind you, this is backwards from Vidya's patch, in which CCS is
described as 8x16 subsampled rather than 16x8. I think yours is
correct though.

Cheers,
Daniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/6] drm/i915: Add format modifiers for Intel

[Daniel Stone]

Hi Ben,

On 26 July 2017 at 19:08, Ben Widawsky  wrote:
> +static bool intel_primary_plane_format_mod_supported(struct drm_plane *plane,
> +uint32_t format,
> +uint64_t modifier)
> +{
> +   struct drm_i915_private *dev_priv = to_i915(plane->dev);
> +
> +   if (WARN_ON(modifier == DRM_FORMAT_MOD_INVALID))
> +   return false;
> +
> +   if (!(modifier & DRM_FORMAT_MOD_VENDOR_INTEL) &&
> +   modifier != DRM_FORMAT_MOD_LINEAR)
> +   return false;

The vendor ID isn't shifted yet, so this comparison is wrong. Even if
it was shifted, they're sequential rather than bitmask, so
NV/QCOM/BROADCOM all match (vendor & INTEL). To fix both of these:
-   if (!(modifier & DRM_FORMAT_MOD_VENDOR_INTEL) &&
-   modifier != DRM_FORMAT_MOD_LINEAR)
+   if ((modifier >> 56) != DRM_FORMAT_MOD_VENDOR_INTEL &&
+   modifier != DRM_FORMAT_MOD_LINEAR)

The practical effect is that this knocked out MOD_Y_TILED and
MOD_Y_TILED_CCS from the list, since they're the only two Intel
modifiers without the low bit set.

Cheers,
Daniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [maintainer-tools PATCH] dim: Add apply and push shorthands for current branch

[Daniel Vetter]

On Mon, Jul 31, 2017 at 04:17:56PM +0200, Thierry Reding wrote:
> From: Thierry Reding 
> 
> The new apply and push commands are shorthands for applying patches to
> and pushing the current branch, respectively.
> 
> Signed-off-by: Thierry Reding 
> ---
>  dim | 27 +++
>  dim.rst |  8 
>  2 files changed, 35 insertions(+)
> 
> diff --git a/dim b/dim
> index c0cbe352b165..036cb092557e 100755
> --- a/dim
> +++ b/dim
> @@ -326,6 +326,20 @@ function git_fetch_helper # remote
>   fi
>  }
>  
> +function git_current_branch
> +{
> + local line branch
> +
> + git branch --list | while read line; do
> + branch="${line#* }"
> +
> + if test "$branch" != "$line"; then
> + echo "$branch"
> + break
> + fi
> + done
> +}

git symbolic-ref -q --short HEAD

is a much shorter way to type this. Can you respin, maybe also updating
the other helper right below here?

Otherwise I think this is perfect, I think I'll add this shorthand for
some of the maintainer commands for handling pull requests too.

Thanks, Daniel

> +
>  function git_is_current_branch # branch
>  {
>   git branch --list $1 | grep -q '\*'
> @@ -739,6 +753,11 @@ function dim_push_fixes
>   dim_push_branch drm-intel-fixes "$@"
>  }
>  
> +function dim_push
> +{
> + dim_push_branch $(git_current_branch) "$@"
> +}
> +
>  # ensure we're on branch $1, and apply patches. the rest of the arguments are
>  # passed to git am.
>  dim_alias_ab=apply-branch
> @@ -930,6 +949,14 @@ function dim_apply_next_fixes
>   dim_apply_branch drm-intel-next-fixes "$@"
>  }
>  
> +# apply patch to current branch, the rest of the arguments are passed to
> +# git am
> +dim_alias_am=apply
> +function dim_apply
> +{
> + dim_apply_branch $(git_current_branch) "$@"
> +}
> +
>  function commit_list_references
>  {
>   local commit remote log
> diff --git a/dim.rst b/dim.rst
> index c004c30ada17..fa9b587d73bb 100644
> --- a/dim.rst
> +++ b/dim.rst
> @@ -198,6 +198,10 @@ apply-queued [*git am arguments*]
>  **apply-branch** shorthands for *drm-intel-fixes*, *drm-intel-next-fixes*, 
> and
>  *drm-intel-next-queued* branches respectively.
>  
> +apply [*git am arguments*]
> +--
> +**apply-branch** shorthand for the current branch.
> +
>  extract-tags *branch* [*git-rangeish*]
>  --
>  This extracts various tags (e.g. Reviewed-by:) from emails and applies them 
> to the
> @@ -232,6 +236,10 @@ push-queued [*git push arguments*]
>  **push-branch** shorthands for *drm-intel-fixes*, *drm-intel-next-fixes*, and
>  *drm-intel-next-queued* branches respectively.
>  
> +push [*git push arguments*]
> +---
> +**push** shorthand for the current branch.
> +
>  rebuild-tip
>  ---
>  Rebuild and push the integration tree.
> -- 
> 2.13.3
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/omap: Rework the rotation-on-crtc hack

[Daniel Vetter]

I want/need to rework the core property handling, and this hack is
getting in the way. But since it's a non-standard propety only used by
legacy userspace we know that this will only every be called from
ioctl code. And never on some other free-standing state struct, where
this old hack wouldn't work either.

v2: don't forget zorder and get_property!

v3: Shadow the legacy state to avoid locking issues in get_property
(Maarten).

v4: Review from Laurent
- Move struct omap_crtc_state into omap_crtc.c
- Clean up comments.
- Don't forget to copy the shadowed state over on duplicate.

v5: Don't forget to update the reset handler (Maarten).

Reviewed-by: Laurent Pinchart  (v4)
Cc: Maarten Lankhorst 
Cc: Tomi Valkeinen 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/omapdrm/omap_crtc.c | 109 
 1 file changed, 72 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 14e8a7738b06..9014085c33df 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -26,6 +26,16 @@
 
 #include "omap_drv.h"
 
+#define to_omap_crtc_state(x) container_of(x, struct omap_crtc_state, base)
+
+struct omap_crtc_state {
+   /* Must be first. */
+   struct drm_crtc_state base;
+   /* Shadow values for legacy userspace support. */
+   unsigned int rotation;
+   unsigned int zpos;
+};
+
 #define to_omap_crtc(x) container_of(x, struct omap_crtc, base)
 
 struct omap_crtc {
@@ -498,39 +508,35 @@ static void omap_crtc_atomic_flush(struct drm_crtc *crtc,
spin_unlock_irq(>dev->event_lock);
 }
 
-static bool omap_crtc_is_plane_prop(struct drm_crtc *crtc,
-   struct drm_property *property)
-{
-   struct drm_device *dev = crtc->dev;
-   struct omap_drm_private *priv = dev->dev_private;
-
-   return property == priv->zorder_prop ||
-   property == crtc->primary->rotation_property;
-}
-
 static int omap_crtc_atomic_set_property(struct drm_crtc *crtc,
 struct drm_crtc_state *state,
 struct drm_property *property,
 uint64_t val)
 {
-   if (omap_crtc_is_plane_prop(crtc, property)) {
-   struct drm_plane_state *plane_state;
-   struct drm_plane *plane = crtc->primary;
-
-   /*
-* Delegate property set to the primary plane. Get the plane
-* state and set the property directly.
-*/
-
-   plane_state = drm_atomic_get_plane_state(state->state, plane);
-   if (IS_ERR(plane_state))
-   return PTR_ERR(plane_state);
+   struct omap_drm_private *priv = crtc->dev->dev_private;
+   struct omap_crtc_state *omap_state = to_omap_crtc_state(state);
+   struct drm_plane_state *plane_state;
 
-   return drm_atomic_plane_set_property(plane, plane_state,
-   property, val);
+   /*
+* Delegate property set to the primary plane. Get the plane state and
+* set the property directly, but keep a shadow copy for the
+* atomic_get_property callback.
+*/
+   plane_state = drm_atomic_get_plane_state(state->state, crtc->primary);
+   if (IS_ERR(plane_state))
+   return PTR_ERR(plane_state);
+
+   if (property == crtc->primary->rotation_property) {
+   plane_state->rotation = val;
+   omap_state->rotation = val;
+   } else if (property == priv->zorder_prop) {
+   plane_state->zpos = val;
+   omap_state->zpos = val;
+   } else {
+   return -EINVAL;
}
 
-   return -EINVAL;
+   return 0;
 }
 
 static int omap_crtc_atomic_get_property(struct drm_crtc *crtc,
@@ -538,28 +544,57 @@ static int omap_crtc_atomic_get_property(struct drm_crtc 
*crtc,
 struct drm_property *property,
 uint64_t *val)
 {
-   if (omap_crtc_is_plane_prop(crtc, property)) {
-   /*
-* Delegate property get to the primary plane. The
-* drm_atomic_plane_get_property() function isn't exported, but
-* can be called through drm_object_property_get_value() as that
-* will call drm_atomic_get_property() for atomic drivers.
-*/
-   return drm_object_property_get_value(>primary->base,
-   property, val);
-   }
+   struct omap_drm_private *priv = crtc->dev->dev_private;
+   struct omap_crtc_state *omap_state = to_omap_crtc_state(state);
+
+   if (property == crtc->primary->rotation_property)

[Bug 101787] colours all messed up

[bugzilla-daemon]

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

--- Comment #11 from 247  ---
no hint on this one?sorry but is really driving me mad...

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] dma-buf/sync_file: Allow multiple sync_files to wrap a single dma-fence

[Gustavo Padovan]

2017-07-31 Daniel Vetter :

> On Sat, Jul 29, 2017 at 12:18:32PM -0300, Gustavo Padovan wrote:
> > Hi Chris,
> > 
> > 2017-07-28 Chris Wilson :
> > 
> > > Up until recently sync_file were create to export a single dma-fence to
> > > userspace, and so we could canabalise a bit insie dma-fence to mark
> > > whether or not we had enable polling for the sync_file itself. However,
> > > with the advent of syncobj, we do allow userspace to create multiple
> > > sync_files for a single dma-fence. (Similarly, that the sw-sync
> > > validation framework also started returning multiple sync-files wrapping
> > > a single dma-fence for a syncpt also triggering the problem.)
> > > 
> > > This patch reverts my suggestion in commit e24165537312
> > > ("dma-buf/sync_file: only enable fence signalling on poll()") to use a
> > > single bit in the shared dma-fence and restores the sync_file->flags for
> > > tracking the bits individually.
> > > 
> > > Reported-by: Gustavo Padovan 
> > > Fixes: f1e8c67123cf ("dma-buf/sw-sync: Use an rbtree to sort fences in 
> > > the timeline")
> > > Fixes: e9083420bbac ("drm: introduce sync objects (v4)")
> > > Signed-off-by: Chris Wilson 
> > > Cc: Sumit Semwal 
> > > Cc: Sean Paul 
> > > Cc: Gustavo Padovan 
> > > Cc: dri-devel@lists.freedesktop.org
> > > Cc:  # v4.13-rc1+
> > > ---
> > >  drivers/dma-buf/sync_file.c | 5 +++--
> > >  include/linux/sync_file.h   | 3 ++-
> > >  2 files changed, 5 insertions(+), 3 deletions(-)
> > 
> > I confirm the patch fixes the sync kselftests for me. Pushed to
> > drm-misc-next.
> 
> You need to cherry-pick this to drm-misc-fixes (using cherry-pick -x to
> make it clear we applied this twice), since the bug is in 4.13.
> drm-misc-next is for stuff that's only needed in 4.14.
> -Daniel

Pushed to drm-misc-fixes now.

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

Re: [PATCH v2 3/4] drm/bridge: dw-hdmi: add cec driver

[Hans Verkuil]

Hi Russell,

Just two small comments below.

After that's fixed you can add my:

Acked-by: Hans Verkuil 

and:

Tested-by: Hans Verkuil 

(on my SolidRun Cubox-i).

On 07/31/2017 04:29 PM, Russell King wrote:
> Add a CEC driver for the dw-hdmi hardware.
> 
> Reviewed-by: Neil Armstrong 
> Signed-off-by: Russell King 
> ---
>  drivers/gpu/drm/bridge/synopsys/Kconfig   |   9 +
>  drivers/gpu/drm/bridge/synopsys/Makefile  |   1 +
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c | 326 
> ++
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.h |  19 ++
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  42 +++-
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.h |   1 +
>  6 files changed, 397 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c
>  create mode 100644 drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.h
> 



> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c 
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c
> new file mode 100644
> index ..52c9d93b9602
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c
> @@ -0,0 +1,326 @@



> +static irqreturn_t dw_hdmi_cec_thread(int irq, void *data)
> +{
> + struct cec_adapter *adap = data;
> + struct dw_hdmi_cec *cec = cec_get_drvdata(adap);
> +
> + if (cec->tx_done) {
> + cec->tx_done = false;
> + cec_transmit_done(adap, cec->tx_status, 0, 0, 0, 0);

Replace by:

cec_transmit_attempt_done(adap, cec->tx_status);

This gets the counters right.

> + }
> + if (cec->rx_done) {
> + cec->rx_done = false;
> + smp_rmb();
> + cec_received_msg(adap, >rx_msg);
> + }
> + return IRQ_HANDLED;
> +}
> +
> +static int dw_hdmi_cec_probe(struct platform_device *pdev)
> +{
> + struct dw_hdmi_cec_data *data = dev_get_platdata(>dev);
> + struct dw_hdmi_cec *cec;
> + int ret;
> +
> + if (!data)
> + return -ENXIO;
> +
> + /*
> +  * Our device is just a convenience - we want to link to the real
> +  * hardware device here, so that userspace can see the association
> +  * between the HDMI hardware and its associated CEC chardev.
> +  */
> + cec = devm_kzalloc(>dev, sizeof(*cec), GFP_KERNEL);
> + if (!cec)
> + return -ENOMEM;
> +
> + cec->irq = data->irq;
> + cec->ops = data->ops;
> + cec->hdmi = data->hdmi;
> +
> + platform_set_drvdata(pdev, cec);
> +
> + dw_hdmi_write(cec, 0, HDMI_CEC_TX_CNT);
> + dw_hdmi_write(cec, ~0, HDMI_CEC_MASK);
> + dw_hdmi_write(cec, ~0, HDMI_IH_MUTE_CEC_STAT0);
> + dw_hdmi_write(cec, 0, HDMI_CEC_POLARITY);
> +
> + cec->adap = cec_allocate_adapter(_hdmi_cec_ops, cec, "dw_hdmi",
> +  CEC_CAP_LOG_ADDRS | CEC_CAP_TRANSMIT |
> +  CEC_CAP_RC, CEC_MAX_LOG_ADDRS);

Add the missing CEC_CAP_PASSTHROUGH capability.

I think I am going to add a new define to media/cec.h:

#define CEC_CAP_DEFAULTS (CEC_CAP_LOG_ADDRS | CEC_CAP_TRANSMIT | \
  CEC_CAP_PASSTHROUGH | CEC_CAP_RC)

to simplify this since these are standard capabilities.

But that's something I'll do later. For now just add CEC_CAP_PASSTHROUGH.

> + if (IS_ERR(cec->adap))
> + return PTR_ERR(cec->adap);
> +
> + /* override the module pointer */
> + cec->adap->owner = THIS_MODULE;
> +
> + ret = devm_add_action(>dev, dw_hdmi_cec_del, cec);
> + if (ret) {
> + cec_delete_adapter(cec->adap);
> + return ret;
> + }
> +
> + ret = devm_request_threaded_irq(>dev, cec->irq,
> + dw_hdmi_cec_hardirq,
> + dw_hdmi_cec_thread, IRQF_SHARED,
> + "dw-hdmi-cec", cec->adap);
> + if (ret < 0)
> + return ret;
> +
> + cec->notify = cec_notifier_get(pdev->dev.parent);
> + if (!cec->notify)
> + return -ENOMEM;
> +
> + ret = cec_register_adapter(cec->adap, pdev->dev.parent);
> + if (ret < 0) {
> + cec_notifier_put(cec->notify);
> + return ret;
> + }
> +
> + /*
> +  * CEC documentation says we must not call cec_delete_adapter
> +  * after a successful call to cec_register_adapter().
> +  */
> + devm_remove_action(>dev, dw_hdmi_cec_del, cec);
> +
> + cec_register_cec_notifier(cec->adap, cec->notify);
> +
> + return 0;
> +}



Thank you for writing this driver!

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

[BISECTED] vc4: f309946 crashes the kernel if vc4 can't allocate buffers

[Noralf Trønnes]

The following commit crashes the kernel if vc4 can't allocate buffers:

drm/vc4: Add an ioctl for labeling GEM BOs for summary stats

It boots fine if I give it enough memory: cma=128M
I'm doing this on a Pi1 with bcm2835_defconfig.

Uncompressing Linux... done, booting the kernel.
[0.00] Booting Linux on physical CPU 0x0
[0.00] random: get_random_bytes called from 
start_kernel+0x30/0x3c8 with crng_init=0
[0.00] Linux version 4.13.0-rc2+ (pi@agl) (gcc version 4.9.3 
(crosstool-NG crosstool-ng-1.22.0-88-g8460611)) #1 Mon Jul 31 15:27:34 
CEST 2017
[0.00] CPU: ARMv6-compatible processor [410fb767] revision 7 
(ARMv7), cr=00c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing 
instruction cache

[0.00] OF: fdt: Machine model: Raspberry Pi Model B Plus Rev 1.2
[0.00] Memory policy: Data cache writeback
[0.00] cma: Reserved 12 MiB at 0x1b00
[0.00] CPU: All CPU(s) started in SVC mode.
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  
Total pages: 113792
[0.00] Kernel command line: earlyprintk console=ttyAMA0 
bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708_fb.fbswap=1 
dma.dmachans=0x7f35 bcm2708.boardrev=0x10 bcm2708.serial=0xa1725dd1 
bcm2708.uart_clock=4800 bcm2708.disk_led_gpio=47 
bcm2708.disk_led_active_low=0 smsc95xx.macaddr=B8:27:EB:72:5D:D1 
vc_mem.mem_base=0x1ec0 vc_mem.mem_size=0x2000  drm.debug=0x0 
cma=12M dwc_otg.lpm_enable=0 console=tty1 console=ttyAMA0,115200 
root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes 
rootwait

[0.00] PID hash table entries: 2048 (order: 1, 8192 bytes)
[0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 
bytes)
[0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 
bytes)
[0.00] Memory: 429820K/458752K available (7168K kernel code, 
527K rwdata, 2204K rodata, 1024K init, 684K bss, 16644K reserved, 12288K 
cma-reserved)

[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
[0.00] vmalloc : 0xdc80 - 0xff80   ( 560 MB)
[0.00] lowmem  : 0xc000 - 0xdc00   ( 448 MB)
[0.00] modules : 0xbf00 - 0xc000   (  16 MB)
[0.00]   .text : 0xc0008000 - 0xc080   (8160 kB)
[0.00]   .init : 0xc0b0 - 0xc0c0   (1024 kB)
[0.00]   .data : 0xc0c0 - 0xc0c83fe0   ( 528 kB)
[0.00].bss : 0xc0c8a3e8 - 0xc0d357dc   ( 685 kB)
[0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[0.00] ftrace: allocating 24917 entries in 74 pages
[0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[0.30] sched_clock: 32 bits at 1000kHz, resolution 1000ns, wraps 
every 2147483647500ns
[0.71] clocksource: timer: mask: 0x max_cycles: 
0x, max_idle_ns: 1911260446275 ns

[0.000155] bcm2835: system timer (irq = 27)
[0.000747] Console: colour dummy device 80x30
[0.001727] console [tty1] enabled
[0.001783] Calibrating delay loop... 697.95 BogoMIPS (lpj=3489792)
[0.060348] pid_max: default: 32768 minimum: 301
[0.060766] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.060840] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 
bytes)

[0.061831] CPU: Testing write buffer coherency: ok
[0.062919] Setting up static identity map for 0x10 - 0x100054
[0.067672] devtmpfs: initialized
[0.076233] VFP support v0.3: implementor 41 architecture 1 part 20 
variant b rev 5
[0.076759] clocksource: jiffies: mask: 0x max_cycles: 
0x, max_idle_ns: 1911260446275 ns

[0.076866] futex hash table entries: 256 (order: -1, 3072 bytes)
[0.078775] pinctrl core: initialized pinctrl subsystem
[0.079456] NET: Registered protocol family 16
[0.082097] DMA: preallocated 256 KiB pool for atomic coherent 
allocations

[0.087731] No ATAGs?
[0.087768] hw-breakpoint: found 6 breakpoint and 1 watchpoint registers.
[0.087882] hw-breakpoint: maximum watchpoint size is 4 bytes.
[0.088208] Serial: AMBA PL011 UART driver
[0.110991] SCSI subsystem initialized
[0.111548] usbcore: registered new interface driver usbfs
[0.111731] usbcore: registered new interface driver hub
[0.111937] usbcore: registered new device driver usb
[0.112719] Advanced Linux Sound Architecture Driver Initialized.
[0.115728] clocksource: Switched to clocksource timer
[0.198960] simple-framebuffer 1eb75000.framebuffer: framebuffer at 
0x1eb75000, 0x85400 bytes, mapped to 0xdc90
[0.199092] simple-framebuffer 1eb75000.framebuffer: format=r5g6b5, 
mode=656x416x16, linelength=1312

[0.205329] Console: switching to colour frame buffer device 82x26
[0.214619] simple-framebuffer 1eb75000.framebuffer: fb0: 

Re: [PATCH v2 4/4] drm/bridge: dw-hdmi: remove CEC engine register definitions

[Hans Verkuil]

On 07/31/2017 04:29 PM, Russell King wrote:
> We don't need the CEC engine register definitions, so let's remove them.
> 
> Signed-off-by: Russell King 

Acked-by: Hans Verkuil 

Regards,

Hans

> ---
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 45 
> ---
>  1 file changed, 45 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h 
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
> index 69644c83a0f8..9d90eb9c46e5 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
> @@ -478,51 +478,6 @@
>  #define HDMI_A_PRESETUP 0x501A
>  #define HDMI_A_SRM_BASE 0x5020
>  
> -/* CEC Engine Registers */
> -#define HDMI_CEC_CTRL   0x7D00
> -#define HDMI_CEC_STAT   0x7D01
> -#define HDMI_CEC_MASK   0x7D02
> -#define HDMI_CEC_POLARITY   0x7D03
> -#define HDMI_CEC_INT0x7D04
> -#define HDMI_CEC_ADDR_L 0x7D05
> -#define HDMI_CEC_ADDR_H 0x7D06
> -#define HDMI_CEC_TX_CNT 0x7D07
> -#define HDMI_CEC_RX_CNT 0x7D08
> -#define HDMI_CEC_TX_DATA0   0x7D10
> -#define HDMI_CEC_TX_DATA1   0x7D11
> -#define HDMI_CEC_TX_DATA2   0x7D12
> -#define HDMI_CEC_TX_DATA3   0x7D13
> -#define HDMI_CEC_TX_DATA4   0x7D14
> -#define HDMI_CEC_TX_DATA5   0x7D15
> -#define HDMI_CEC_TX_DATA6   0x7D16
> -#define HDMI_CEC_TX_DATA7   0x7D17
> -#define HDMI_CEC_TX_DATA8   0x7D18
> -#define HDMI_CEC_TX_DATA9   0x7D19
> -#define HDMI_CEC_TX_DATA10  0x7D1a
> -#define HDMI_CEC_TX_DATA11  0x7D1b
> -#define HDMI_CEC_TX_DATA12  0x7D1c
> -#define HDMI_CEC_TX_DATA13  0x7D1d
> -#define HDMI_CEC_TX_DATA14  0x7D1e
> -#define HDMI_CEC_TX_DATA15  0x7D1f
> -#define HDMI_CEC_RX_DATA0   0x7D20
> -#define HDMI_CEC_RX_DATA1   0x7D21
> -#define HDMI_CEC_RX_DATA2   0x7D22
> -#define HDMI_CEC_RX_DATA3   0x7D23
> -#define HDMI_CEC_RX_DATA4   0x7D24
> -#define HDMI_CEC_RX_DATA5   0x7D25
> -#define HDMI_CEC_RX_DATA6   0x7D26
> -#define HDMI_CEC_RX_DATA7   0x7D27
> -#define HDMI_CEC_RX_DATA8   0x7D28
> -#define HDMI_CEC_RX_DATA9   0x7D29
> -#define HDMI_CEC_RX_DATA10  0x7D2a
> -#define HDMI_CEC_RX_DATA11  0x7D2b
> -#define HDMI_CEC_RX_DATA12  0x7D2c
> -#define HDMI_CEC_RX_DATA13  0x7D2d
> -#define HDMI_CEC_RX_DATA14  0x7D2e
> -#define HDMI_CEC_RX_DATA15  0x7D2f
> -#define HDMI_CEC_LOCK   0x7D30
> -#define HDMI_CEC_WKUPCTRL   0x7D31
> -
>  /* I2C Master Registers (E-DDC) */
>  #define HDMI_I2CM_SLAVE 0x7E00
>  #define HDMI_I2CM_ADDRESS   0x7E01
> 

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

Re: [PATCH v2 2/4] drm/bridge: dw-hdmi: add better clock disable control

[Hans Verkuil]

On 07/31/2017 04:29 PM, Russell King wrote:
> The video setup path aways sets the clock disable register to a specific
> value, which has the effect of disabling the CEC engine.  When we add the
> CEC driver, this becomes a problem.
> 
> Fix this by only setting/clearing the bits that the video path needs to.
> 
> Reviewed-by: Jose Abreu 
> Signed-off-by: Russell King 

Acked-by: Hans Verkuil 

Regards,

Hans

> ---
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 29 ++---
>  1 file changed, 18 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index 82e55ee8e4fa..b08cc0c95590 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -166,6 +166,7 @@ struct dw_hdmi {
>   bool bridge_is_on;  /* indicates the bridge is on */
>   bool rxsense;   /* rxsense state */
>   u8 phy_mask;/* desired phy int mask settings */
> + u8 mc_clkdis;   /* clock disable register */
>  
>   spinlock_t audio_lock;
>   struct mutex audio_mutex;
> @@ -551,8 +552,11 @@ EXPORT_SYMBOL_GPL(dw_hdmi_set_sample_rate);
>  
>  static void hdmi_enable_audio_clk(struct dw_hdmi *hdmi, bool enable)
>  {
> - hdmi_modb(hdmi, enable ? 0 : HDMI_MC_CLKDIS_AUDCLK_DISABLE,
> -   HDMI_MC_CLKDIS_AUDCLK_DISABLE, HDMI_MC_CLKDIS);
> + if (enable)
> + hdmi->mc_clkdis &= ~HDMI_MC_CLKDIS_AUDCLK_DISABLE;
> + else
> + hdmi->mc_clkdis |= HDMI_MC_CLKDIS_AUDCLK_DISABLE;
> + hdmi_writeb(hdmi, hdmi->mc_clkdis, HDMI_MC_CLKDIS);
>  }
>  
>  static void dw_hdmi_ahb_audio_enable(struct dw_hdmi *hdmi)
> @@ -1574,8 +1578,6 @@ static void hdmi_av_composer(struct dw_hdmi *hdmi,
>  /* HDMI Initialization Step B.4 */
>  static void dw_hdmi_enable_video_path(struct dw_hdmi *hdmi)
>  {
> - u8 clkdis;
> -
>   /* control period minimum duration */
>   hdmi_writeb(hdmi, 12, HDMI_FC_CTRLDUR);
>   hdmi_writeb(hdmi, 32, HDMI_FC_EXCTRLDUR);
> @@ -1587,17 +1589,21 @@ static void dw_hdmi_enable_video_path(struct dw_hdmi 
> *hdmi)
>   hdmi_writeb(hdmi, 0x21, HDMI_FC_CH2PREAM);
>  
>   /* Enable pixel clock and tmds data path */
> - clkdis = 0x7F;
> - clkdis &= ~HDMI_MC_CLKDIS_PIXELCLK_DISABLE;
> - hdmi_writeb(hdmi, clkdis, HDMI_MC_CLKDIS);
> + hdmi->mc_clkdis |= HDMI_MC_CLKDIS_HDCPCLK_DISABLE |
> +HDMI_MC_CLKDIS_CSCCLK_DISABLE |
> +HDMI_MC_CLKDIS_AUDCLK_DISABLE |
> +HDMI_MC_CLKDIS_PREPCLK_DISABLE |
> +HDMI_MC_CLKDIS_TMDSCLK_DISABLE;
> + hdmi->mc_clkdis &= ~HDMI_MC_CLKDIS_PIXELCLK_DISABLE;
> + hdmi_writeb(hdmi, hdmi->mc_clkdis, HDMI_MC_CLKDIS);
>  
> - clkdis &= ~HDMI_MC_CLKDIS_TMDSCLK_DISABLE;
> - hdmi_writeb(hdmi, clkdis, HDMI_MC_CLKDIS);
> + hdmi->mc_clkdis &= ~HDMI_MC_CLKDIS_TMDSCLK_DISABLE;
> + hdmi_writeb(hdmi, hdmi->mc_clkdis, HDMI_MC_CLKDIS);
>  
>   /* Enable csc path */
>   if (is_color_space_conversion(hdmi)) {
> - clkdis &= ~HDMI_MC_CLKDIS_CSCCLK_DISABLE;
> - hdmi_writeb(hdmi, clkdis, HDMI_MC_CLKDIS);
> + hdmi->mc_clkdis &= ~HDMI_MC_CLKDIS_CSCCLK_DISABLE;
> + hdmi_writeb(hdmi, hdmi->mc_clkdis, HDMI_MC_CLKDIS);
>   }
>  
>   /* Enable color space conversion if needed */
> @@ -2272,6 +2278,7 @@ __dw_hdmi_probe(struct platform_device *pdev,
>   hdmi->disabled = true;
>   hdmi->rxsense = true;
>   hdmi->phy_mask = (u8)~(HDMI_PHY_HPD | HDMI_PHY_RX_SENSE);
> + hdmi->mc_clkdis = 0x7f;
>  
>   mutex_init(>mutex);
>   mutex_init(>audio_mutex);
> 

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

Re: [PATCH v2 1/4] drm/bridge: dw-hdmi: add cec notifier support

[Hans Verkuil]

On 07/31/2017 04:29 PM, Russell King wrote:
> Add CEC notifier support to the HDMI bridge driver, so that the CEC
> part of the IP can receive its physical address.
> 
> Signed-off-by: Russell King 

Acked-by: Hans Verkuil 

Regards,

Hans

> ---
>  drivers/gpu/drm/bridge/synopsys/Kconfig   |  1 +
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 22 +-
>  2 files changed, 22 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/bridge/synopsys/Kconfig 
> b/drivers/gpu/drm/bridge/synopsys/Kconfig
> index 53e78d092d18..351db000599a 100644
> --- a/drivers/gpu/drm/bridge/synopsys/Kconfig
> +++ b/drivers/gpu/drm/bridge/synopsys/Kconfig
> @@ -2,6 +2,7 @@ config DRM_DW_HDMI
>   tristate
>   select DRM_KMS_HELPER
>   select REGMAP_MMIO
> + select CEC_CORE if CEC_NOTIFIER
>  
>  config DRM_DW_HDMI_AHB_AUDIO
>   tristate "Synopsys Designware AHB Audio interface"
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index ead11242c4b9..82e55ee8e4fa 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -36,7 +36,10 @@
>  #include "dw-hdmi.h"
>  #include "dw-hdmi-audio.h"
>  
> +#include 
> +
>  #define DDC_SEGMENT_ADDR 0x30
> +
>  #define HDMI_EDID_LEN512
>  
>  enum hdmi_datamap {
> @@ -175,6 +178,8 @@ struct dw_hdmi {
>   struct regmap *regm;
>   void (*enable_audio)(struct dw_hdmi *hdmi);
>   void (*disable_audio)(struct dw_hdmi *hdmi);
> +
> + struct cec_notifier *cec_notifier;
>  };
>  
>  #define HDMI_IH_PHY_STAT0_RX_SENSE \
> @@ -1896,6 +1901,7 @@ static int dw_hdmi_connector_get_modes(struct 
> drm_connector *connector)
>   hdmi->sink_is_hdmi = drm_detect_hdmi_monitor(edid);
>   hdmi->sink_has_audio = drm_detect_monitor_audio(edid);
>   drm_mode_connector_update_edid_property(connector, edid);
> + cec_notifier_set_phys_addr_from_edid(hdmi->cec_notifier, edid);
>   ret = drm_add_edid_modes(connector, edid);
>   /* Store the ELD */
>   drm_edid_to_eld(connector, edid);
> @@ -2119,11 +2125,16 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
>* ask the source to re-read the EDID.
>*/
>   if (intr_stat &
> - (HDMI_IH_PHY_STAT0_RX_SENSE | HDMI_IH_PHY_STAT0_HPD))
> + (HDMI_IH_PHY_STAT0_RX_SENSE | HDMI_IH_PHY_STAT0_HPD)) {
>   __dw_hdmi_setup_rx_sense(hdmi,
>phy_stat & HDMI_PHY_HPD,
>phy_stat & HDMI_PHY_RX_SENSE);
>  
> + if ((phy_stat & (HDMI_PHY_RX_SENSE | HDMI_PHY_HPD)) == 0)
> + cec_notifier_set_phys_addr(hdmi->cec_notifier,
> +CEC_PHYS_ADDR_INVALID);
> + }
> +
>   if (intr_stat & HDMI_IH_PHY_STAT0_HPD) {
>   dev_dbg(hdmi->dev, "EVENT=%s\n",
>   phy_int_pol & HDMI_PHY_HPD ? "plugin" : "plugout");
> @@ -2376,6 +2387,12 @@ __dw_hdmi_probe(struct platform_device *pdev,
>   if (ret)
>   goto err_iahb;
>  
> + hdmi->cec_notifier = cec_notifier_get(dev);
> + if (!hdmi->cec_notifier) {
> + ret = -ENOMEM;
> + goto err_iahb;
> + }
> +
>   /*
>* To prevent overflows in HDMI_IH_FC_STAT2, set the clk regenerator
>* N and cts values before enabling phy
> @@ -2452,6 +2469,9 @@ __dw_hdmi_probe(struct platform_device *pdev,
>   hdmi->ddc = NULL;
>   }
>  
> + if (hdmi->cec_notifier)
> + cec_notifier_put(hdmi->cec_notifier);
> +
>   clk_disable_unprepare(hdmi->iahb_clk);
>  err_isfr:
>   clk_disable_unprepare(hdmi->isfr_clk);
> 

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

[Bug 101961] Serious Sam Fusion hangs system completely

[bugzilla-daemon]

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

Marek Olšák  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #6 from Marek Olšák  ---
I reverted 5c1241268b. Please reopen if you still get the hang.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/4] drm/bridge: dw-hdmi: add cec notifier support

[Neil Armstrong]

On 07/31/2017 04:29 PM, Russell King wrote:
> Add CEC notifier support to the HDMI bridge driver, so that the CEC
> part of the IP can receive its physical address.
> 
> Signed-off-by: Russell King 
> ---
>  drivers/gpu/drm/bridge/synopsys/Kconfig   |  1 +
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 22 +-
>  2 files changed, 22 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/bridge/synopsys/Kconfig 
> b/drivers/gpu/drm/bridge/synopsys/Kconfig
> index 53e78d092d18..351db000599a 100644
> --- a/drivers/gpu/drm/bridge/synopsys/Kconfig
> +++ b/drivers/gpu/drm/bridge/synopsys/Kconfig
> @@ -2,6 +2,7 @@ config DRM_DW_HDMI
>   tristate
>   select DRM_KMS_HELPER
>   select REGMAP_MMIO
> + select CEC_CORE if CEC_NOTIFIER
>  
>  config DRM_DW_HDMI_AHB_AUDIO
>   tristate "Synopsys Designware AHB Audio interface"
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index ead11242c4b9..82e55ee8e4fa 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -36,7 +36,10 @@
>  #include "dw-hdmi.h"
>  #include "dw-hdmi-audio.h"
>  
> +#include 
> +
>  #define DDC_SEGMENT_ADDR 0x30
> +
>  #define HDMI_EDID_LEN512
>  
>  enum hdmi_datamap {
> @@ -175,6 +178,8 @@ struct dw_hdmi {
>   struct regmap *regm;
>   void (*enable_audio)(struct dw_hdmi *hdmi);
>   void (*disable_audio)(struct dw_hdmi *hdmi);
> +
> + struct cec_notifier *cec_notifier;
>  };
>  
>  #define HDMI_IH_PHY_STAT0_RX_SENSE \
> @@ -1896,6 +1901,7 @@ static int dw_hdmi_connector_get_modes(struct 
> drm_connector *connector)
>   hdmi->sink_is_hdmi = drm_detect_hdmi_monitor(edid);
>   hdmi->sink_has_audio = drm_detect_monitor_audio(edid);
>   drm_mode_connector_update_edid_property(connector, edid);
> + cec_notifier_set_phys_addr_from_edid(hdmi->cec_notifier, edid);
>   ret = drm_add_edid_modes(connector, edid);
>   /* Store the ELD */
>   drm_edid_to_eld(connector, edid);
> @@ -2119,11 +2125,16 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
>* ask the source to re-read the EDID.
>*/
>   if (intr_stat &
> - (HDMI_IH_PHY_STAT0_RX_SENSE | HDMI_IH_PHY_STAT0_HPD))
> + (HDMI_IH_PHY_STAT0_RX_SENSE | HDMI_IH_PHY_STAT0_HPD)) {
>   __dw_hdmi_setup_rx_sense(hdmi,
>phy_stat & HDMI_PHY_HPD,
>phy_stat & HDMI_PHY_RX_SENSE);
>  
> + if ((phy_stat & (HDMI_PHY_RX_SENSE | HDMI_PHY_HPD)) == 0)
> + cec_notifier_set_phys_addr(hdmi->cec_notifier,
> +CEC_PHYS_ADDR_INVALID);
> + }
> +
>   if (intr_stat & HDMI_IH_PHY_STAT0_HPD) {
>   dev_dbg(hdmi->dev, "EVENT=%s\n",
>   phy_int_pol & HDMI_PHY_HPD ? "plugin" : "plugout");
> @@ -2376,6 +2387,12 @@ __dw_hdmi_probe(struct platform_device *pdev,
>   if (ret)
>   goto err_iahb;
>  
> + hdmi->cec_notifier = cec_notifier_get(dev);
> + if (!hdmi->cec_notifier) {
> + ret = -ENOMEM;
> + goto err_iahb;
> + }
> +
>   /*
>* To prevent overflows in HDMI_IH_FC_STAT2, set the clk regenerator
>* N and cts values before enabling phy
> @@ -2452,6 +2469,9 @@ __dw_hdmi_probe(struct platform_device *pdev,
>   hdmi->ddc = NULL;
>   }
>  
> + if (hdmi->cec_notifier)
> + cec_notifier_put(hdmi->cec_notifier);
> +
>   clk_disable_unprepare(hdmi->iahb_clk);
>  err_isfr:
>   clk_disable_unprepare(hdmi->isfr_clk);
> 

Tested-by: Neil Armstrong 
Reviewed-by: Neil Armstrong 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: todo: Avoid accidental crossreferences

[Thierry Reding]

On Mon, Jul 31, 2017 at 02:47:12PM +0200, Daniel Vetter wrote:
> On Mon, Jul 31, 2017 at 02:42:59PM +0200, Thierry Reding wrote:
> > From: Thierry Reding 
> > 
> > RST uses underscores at the end of words to create crossreferences and
> > it will accidentally try to link to tinydrm_ and drm_fb_ targets from
> > the TODO, which is clearly not the intention in this context.
> > 
> > Use backslashes to escape the special meaning of the underscore.
> 
> Yeah that's one of the things where rst gets a bit in the way of just
> plain text. Another one is * at the end ...
> 
> Reviewed-by: Daniel Vetter 

Applied, thanks.

Thierry


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[maintainer-tools PATCH] dim: Add apply and push shorthands for current branch

[Thierry Reding]

From: Thierry Reding 

The new apply and push commands are shorthands for applying patches to
and pushing the current branch, respectively.

Signed-off-by: Thierry Reding 
---
 dim | 27 +++
 dim.rst |  8 
 2 files changed, 35 insertions(+)

diff --git a/dim b/dim
index c0cbe352b165..036cb092557e 100755
--- a/dim
+++ b/dim
@@ -326,6 +326,20 @@ function git_fetch_helper # remote
fi
 }
 
+function git_current_branch
+{
+   local line branch
+
+   git branch --list | while read line; do
+   branch="${line#* }"
+
+   if test "$branch" != "$line"; then
+   echo "$branch"
+   break
+   fi
+   done
+}
+
 function git_is_current_branch # branch
 {
git branch --list $1 | grep -q '\*'
@@ -739,6 +753,11 @@ function dim_push_fixes
dim_push_branch drm-intel-fixes "$@"
 }
 
+function dim_push
+{
+   dim_push_branch $(git_current_branch) "$@"
+}
+
 # ensure we're on branch $1, and apply patches. the rest of the arguments are
 # passed to git am.
 dim_alias_ab=apply-branch
@@ -930,6 +949,14 @@ function dim_apply_next_fixes
dim_apply_branch drm-intel-next-fixes "$@"
 }
 
+# apply patch to current branch, the rest of the arguments are passed to
+# git am
+dim_alias_am=apply
+function dim_apply
+{
+   dim_apply_branch $(git_current_branch) "$@"
+}
+
 function commit_list_references
 {
local commit remote log
diff --git a/dim.rst b/dim.rst
index c004c30ada17..fa9b587d73bb 100644
--- a/dim.rst
+++ b/dim.rst
@@ -198,6 +198,10 @@ apply-queued [*git am arguments*]
 **apply-branch** shorthands for *drm-intel-fixes*, *drm-intel-next-fixes*, and
 *drm-intel-next-queued* branches respectively.
 
+apply [*git am arguments*]
+--
+**apply-branch** shorthand for the current branch.
+
 extract-tags *branch* [*git-rangeish*]
 --
 This extracts various tags (e.g. Reviewed-by:) from emails and applies them to 
the
@@ -232,6 +236,10 @@ push-queued [*git push arguments*]
 **push-branch** shorthands for *drm-intel-fixes*, *drm-intel-next-fixes*, and
 *drm-intel-next-queued* branches respectively.
 
+push [*git push arguments*]
+---
+**push** shorthand for the current branch.
+
 rebuild-tip
 ---
 Rebuild and push the integration tree.
-- 
2.13.3

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

[Bug 194761] amdgpu driver breaks on Oland (SI)

[bugzilla-daemon]

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

--- Comment #81 from Alexander Tsoy (alexan...@tsoy.me) ---
(In reply to Jean Delvare from comment #80)
> I tested the patch from comment #78 and unfortunately I have to report that
> it doesn't fix the problem for me, checkerboard effect is still present.
It doesn't fix the problem for me as well.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] dma-buf: fix reservation_object_wait_timeout_rcu to wait correctly v2

[Christian König]

Ping, what do you guys think of that?

Am 25.07.2017 um 15:35 schrieb Christian König:

From: Christian König 

With hardware resets in mind it is possible that all shared fences are
signaled, but the exlusive isn't. Fix waiting for everything in this situation.

v2: make sure we always wait for the exclusive fence

Signed-off-by: Christian König 
---
  drivers/dma-buf/reservation.c | 33 +++--
  1 file changed, 15 insertions(+), 18 deletions(-)

diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index 393817e..9d4316d 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -373,12 +373,25 @@ long reservation_object_wait_timeout_rcu(struct 
reservation_object *obj,
long ret = timeout ? timeout : 1;
  
  retry:

-   fence = NULL;
shared_count = 0;
seq = read_seqcount_begin(>seq);
rcu_read_lock();
  
-	if (wait_all) {

+   fence = rcu_dereference(obj->fence_excl);
+   if (fence && !test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags)) {
+   if (!dma_fence_get_rcu(fence))
+   goto unlock_retry;
+
+   if (dma_fence_is_signaled(fence)) {
+   dma_fence_put(fence);
+   fence = NULL;
+   }
+
+   } else {
+   fence = NULL;
+   }
+
+   if (!fence && wait_all) {
struct reservation_object_list *fobj =
rcu_dereference(obj->fence);
  
@@ -405,22 +418,6 @@ long reservation_object_wait_timeout_rcu(struct reservation_object *obj,

}
}
  
-	if (!shared_count) {

-   struct dma_fence *fence_excl = rcu_dereference(obj->fence_excl);
-
-   if (fence_excl &&
-   !test_bit(DMA_FENCE_FLAG_SIGNALED_BIT,
- _excl->flags)) {
-   if (!dma_fence_get_rcu(fence_excl))
-   goto unlock_retry;
-
-   if (dma_fence_is_signaled(fence_excl))
-   dma_fence_put(fence_excl);
-   else
-   fence = fence_excl;
-   }
-   }
-
rcu_read_unlock();
if (fence) {
if (read_seqcount_retry(>seq, seq)) {



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

Re: [PATCH] drm: Fix kerneldoc for atomic_async_update

[Gustavo Padovan]

2017-07-31 Daniel Vetter :

> The enumeration of FIXMEs wasn't indented properly.
> 
> Fixes: fef9df8b5945 ("drm/atomic: initial support for asynchronous plane 
> update")
> Cc: Gustavo Padovan 
> Signed-off-by: Daniel Vetter 
> ---
>  include/drm/drm_modeset_helper_vtables.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/include/drm/drm_modeset_helper_vtables.h 
> b/include/drm/drm_modeset_helper_vtables.h
> index 06569845708c..810c2aae9d81 100644
> --- a/include/drm/drm_modeset_helper_vtables.h
> +++ b/include/drm/drm_modeset_helper_vtables.h
> @@ -1179,9 +1179,9 @@ struct drm_plane_helper_funcs {
>*  - It only works for single plane updates
>*  - Async Pageflips are not supported yet
>*  - Some hw might still scan out the old buffer until the next
> -  *  vblank, however we let go of the fb references as soon as
> -  *  we run this hook. For now drivers must implement their own workers
> -  *  for deferring if needed, until a common solution is created.
> +  *vblank, however we let go of the fb references as soon as
> +  *we run this hook. For now drivers must implement their own workers
> +  *for deferring if needed, until a common solution is created.
>*/
>   void (*atomic_async_update)(struct drm_plane *plane,
>   struct drm_plane_state *new_state);

Reviewed-by: Gustavo Padovan 

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

[Bug 99553] Tracker bug for runnning OpenCL applications on Clover

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99553
Bug 99553 depends on bug 101952, which changed state.

Bug 101952 Summary: OpenCL enqueueReadBuffer returns trash
https://bugs.freedesktop.org/show_bug.cgi?id=101952

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/omap: Rework the rotation-on-crtc hack

[Laurent Pinchart]

Hi Daniel,

Thank you for the patch.

On Monday 31 Jul 2017 14:45:16 Daniel Vetter wrote:
> I want/need to rework the core property handling, and this hack is
> getting in the way. But since it's a non-standard propety only used by
> legacy userspace we know that this will only every be called from
> ioctl code. And never on some other free-standing state struct, where
> this old hack wouldn't work either.
> 
> v2: don't forget zorder and get_property!
> 
> v3: Shadow the legacy state to avoid locking issues in get_property
> (Maarten).
> 
> v4: Review from Laurent
> - Move struct omap_crtc_state into omap_crtc.c
> - Clean up comments.
> - Don't forget to copy the shadowed state over on duplicate.
> 
> Cc: Maarten Lankhorst 
> Cc: Tomi Valkeinen  Cc: Laurent Pinchart 
> Signed-off-by: Daniel Vetter 

I wish we could do better, but I think that's the best we can achieve without 
removing the hack.

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/omapdrm/omap_crtc.c | 95 --
>  1 file changed, 59 insertions(+), 36 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
> b/drivers/gpu/drm/omapdrm/omap_crtc.c index 14e8a7738b06..16d8b291921b
> 100644
> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
> @@ -26,6 +26,16 @@
> 
>  #include "omap_drv.h"
> 
> +#define to_omap_crtc_state(x) container_of(x, struct omap_crtc_state, base)
> +
> +struct omap_crtc_state {
> + /* Must be first. */
> + struct drm_crtc_state base;
> + /* Shadow values for legacy userspace support. */
> + unsigned int rotation;
> + unsigned int zpos;
> +};
> +
>  #define to_omap_crtc(x) container_of(x, struct omap_crtc, base)
> 
>  struct omap_crtc {
> @@ -498,39 +508,35 @@ static void omap_crtc_atomic_flush(struct drm_crtc
> *crtc, spin_unlock_irq(>dev->event_lock);
>  }
> 
> -static bool omap_crtc_is_plane_prop(struct drm_crtc *crtc,
> - struct drm_property *property)
> -{
> - struct drm_device *dev = crtc->dev;
> - struct omap_drm_private *priv = dev->dev_private;
> -
> - return property == priv->zorder_prop ||
> - property == crtc->primary->rotation_property;
> -}
> -
>  static int omap_crtc_atomic_set_property(struct drm_crtc *crtc,
>struct drm_crtc_state *state,
>struct drm_property *property,
>uint64_t val)
>  {
> - if (omap_crtc_is_plane_prop(crtc, property)) {
> - struct drm_plane_state *plane_state;
> - struct drm_plane *plane = crtc->primary;
> -
> - /*
> -  * Delegate property set to the primary plane. Get the plane
> -  * state and set the property directly.
> -  */
> -
> - plane_state = drm_atomic_get_plane_state(state->state, plane);
> - if (IS_ERR(plane_state))
> - return PTR_ERR(plane_state);
> + struct omap_drm_private *priv = crtc->dev->dev_private;
> + struct omap_crtc_state *omap_state = to_omap_crtc_state(state);
> + struct drm_plane_state *plane_state;
> 
> - return drm_atomic_plane_set_property(plane, plane_state,
> - property, val);
> + /*
> +  * Delegate property set to the primary plane. Get the plane state and
> +  * set the property directly, but keep a shadow copy for the
> +  * atomic_get_property callback.
> +  */
> + plane_state = drm_atomic_get_plane_state(state->state, crtc->primary);
> + if (IS_ERR(plane_state))
> + return PTR_ERR(plane_state);
> +
> + if (property == crtc->primary->rotation_property) {
> + plane_state->rotation = val;
> + omap_state->rotation = val;
> + } else if (property == priv->zorder_prop) {
> + plane_state->zpos = val;
> + omap_state->zpos = val;
> + } else {
> + return -EINVAL;
>   }
> 
> - return -EINVAL;
> + return 0;
>  }
> 
>  static int omap_crtc_atomic_get_property(struct drm_crtc *crtc,
> @@ -538,20 +544,37 @@ static int omap_crtc_atomic_get_property(struct
> drm_crtc *crtc, struct drm_property *property,
>uint64_t *val)
>  {
> - if (omap_crtc_is_plane_prop(crtc, property)) {
> - /*
> -  * Delegate property get to the primary plane. The
> -  * drm_atomic_plane_get_property() function isn't exported, 
but
> -  * can be called through drm_object_property_get_value() as 
that
> -  * will call drm_atomic_get_property() for atomic drivers.
> -  */
> - return drm_object_property_get_value(>primary->base,
> - property, val);
> - }

Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900

[Tomi Valkeinen]

On 30/06/17 15:36, Daniel Vetter wrote:

> I don't think registering before everything is loaded make sense. On the
> big desktop driver chips we have all the bridge/encoder/panel drivers
> built into the driver. arm-soc loves to make everything a separate module,
> but in the end if you decided to not compile half of the driver you need,
> then it's not going to work.

I don't think that's quite the same. On the desktop you just have the
video card, and it's easy to enable that single component. On an
embedded device you have the SoC's display controller and then possibly
multiple external encoders/panels on the board. Those external
components have to be separate modules, they can't be part of the SoC
driver. The desktop video card matches only to the SoC's display controller.

> Imo the only thing we should support to be hotplugged in drm is stuff you
> can physically hotplug (like atm connectors). Everything else just
> complicates the code for no good reason at all.

"unplugging" components would not give much, I think, but allowing
adding new displays at runtime would be a very good thing.

It's not only about mistakenly having the driver disabled in the kernel
config, it could also be that some base driver failed to probe, which
then makes an encoder or a panel to defer probing as it can't get the
base resource. But HDMI or some other panel would work fine, but with
current architecture can't be used.

And if you really want to optimize, one a phone-type device you could
have the LCD driver built-in, but HDMI drivers as modules, and only load
the HDMI drivers if the user actually needs the HDMI.

 Tomi



signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101518] [BAT][SKL] WARNING: no modes for connector 48 when running igt@kms_setmode@basic-clone-single-crtc

[bugzilla-daemon]

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

Martin Peres  changed:

   What|Removed |Added

   Assignee|dri-devel@lists.freedesktop |manasi.d.nav...@intel.com
   |.org|

--- Comment #7 from Martin Peres  ---
Assigning Manasi to this issue, because it is a fallout of the link-status
patch.

We may argue all we want about whether the platform is bad or not, but the
tests are for sure wrong since they don't check for their dependencies. Sorry
to through you under the bus Manasi, but this is only a problem after your
patch.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900

[Tomi Valkeinen]

On 04/07/17 18:09, Pavel Machek wrote:
> Hi!
> 
>> Are you sure it doesn't probe? It fails the omapdss_stack_is_ready()
>> check?
>
> It appears the reason was that I didn't have
> CONFIG_DRM_OMAP_CONNECTOR_ANALOG_TV enabled.
>
> I think that's wrong. I don't own an analog TV, so why should I enable
> such option to get device's built-in display working?

 Indeed. Unfortunately I don't have a solution for that.

 DRM doesn't support adding devices after probe. So at omapdrm probe time
 we have to decide which displays to use. In the dts file, n900 defines
 the lcd and analog tv. omapdrm sees those, and, of course, must wait
 until their respective drivers have probed. If you don't have the
 display driver enabled, it's never loaded and omapdrm never probes as it
 keeps waiting for those.
>>>
>>> Could you at least print some kind of message early in the boot ("omapdrm
>>> is waiting for drivers for display x and y")?
>>
>> That could be quite spammy. omapdrm will defer probe if the displays are
>> not present, and the deferred probing machinery will then cause a new
>> omapdrm probe later. That can happen a lot of times before the drivers
>> are there.
> 
> Well doing printk just once should not be a problem...?

I'm not sure if that would really help much... And you would practically
always see the print, even when everything works fine, which would be
useless and could raise false alarms.

 Tomi



signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/bridge: dw_hdmi: add cec notifier support

[Neil Armstrong]

From: Russell King 

Add CEC notifier support to the HDMI bridge driver, so that the CEC
part of the IP can receive its physical address.

Tested-by: Neil Armstrong 
Acked-by: Neil Armstrong 
Acked-by: Hans Verkuil 
Signed-off-by: Russell King 
[narmstrong: added kconfig tweak to get the right modules dependencies]
Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/bridge/synopsys/Kconfig   |  1 +
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 18 ++
 2 files changed, 19 insertions(+)

Hi Archit, Hans,

This is second repost of Russell's patch from his dw-hdmi CEC patchset.

Latest russell's thread :
https://lkml.kernel.org/r/e1dfi3e-0004lh...@rmk-pc.armlinux.org.uk

Previous repost :
https://lkml.kernel.org/r/1499337186-24429-1-git-send-email-narmstr...@baylibre.com

It includes the Kconfig tweak to ensure the correct modules dependencies.

Neil

diff --git a/drivers/gpu/drm/bridge/synopsys/Kconfig 
b/drivers/gpu/drm/bridge/synopsys/Kconfig
index 53e78d0..351db00 100644
--- a/drivers/gpu/drm/bridge/synopsys/Kconfig
+++ b/drivers/gpu/drm/bridge/synopsys/Kconfig
@@ -2,6 +2,7 @@ config DRM_DW_HDMI
tristate
select DRM_KMS_HELPER
select REGMAP_MMIO
+   select CEC_CORE if CEC_NOTIFIER
 
 config DRM_DW_HDMI_AHB_AUDIO
tristate "Synopsys Designware AHB Audio interface"
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index ead1124..9c03846 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -33,6 +33,8 @@
 #include 
 #include 
 
+#include 
+
 #include "dw-hdmi.h"
 #include "dw-hdmi-audio.h"
 
@@ -175,6 +177,8 @@ struct dw_hdmi {
struct regmap *regm;
void (*enable_audio)(struct dw_hdmi *hdmi);
void (*disable_audio)(struct dw_hdmi *hdmi);
+
+   struct cec_notifier *cec_notifier;
 };
 
 #define HDMI_IH_PHY_STAT0_RX_SENSE \
@@ -1896,6 +1900,7 @@ static int dw_hdmi_connector_get_modes(struct 
drm_connector *connector)
hdmi->sink_is_hdmi = drm_detect_hdmi_monitor(edid);
hdmi->sink_has_audio = drm_detect_monitor_audio(edid);
drm_mode_connector_update_edid_property(connector, edid);
+   cec_notifier_set_phys_addr_from_edid(hdmi->cec_notifier, edid);
ret = drm_add_edid_modes(connector, edid);
/* Store the ELD */
drm_edid_to_eld(connector, edid);
@@ -2077,6 +2082,10 @@ void __dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi, bool 
hpd, bool rx_sense)
dw_hdmi_update_phy_mask(hdmi);
}
mutex_unlock(>mutex);
+
+   if (!rx_sense && !hpd)
+   cec_notifier_set_phys_addr(hdmi->cec_notifier,
+  CEC_PHYS_ADDR_INVALID);
 }
 
 void dw_hdmi_setup_rx_sense(struct device *dev, bool hpd, bool rx_sense)
@@ -2376,6 +2385,12 @@ static int dw_hdmi_detect_phy(struct dw_hdmi *hdmi)
if (ret)
goto err_iahb;
 
+   hdmi->cec_notifier = cec_notifier_get(dev);
+   if (!hdmi->cec_notifier) {
+   ret = -ENOMEM;
+   goto err_iahb;
+   }
+
/*
 * To prevent overflows in HDMI_IH_FC_STAT2, set the clk regenerator
 * N and cts values before enabling phy
@@ -2452,6 +2467,9 @@ static int dw_hdmi_detect_phy(struct dw_hdmi *hdmi)
hdmi->ddc = NULL;
}
 
+   if (hdmi->cec_notifier)
+   cec_notifier_put(hdmi->cec_notifier);
+
clk_disable_unprepare(hdmi->iahb_clk);
 err_isfr:
clk_disable_unprepare(hdmi->isfr_clk);
-- 
1.9.1

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

Re: [PATCH] drm: todo: Avoid accidental crossreferences

[Daniel Vetter]

On Mon, Jul 31, 2017 at 02:42:59PM +0200, Thierry Reding wrote:
> From: Thierry Reding 
> 
> RST uses underscores at the end of words to create crossreferences and
> it will accidentally try to link to tinydrm_ and drm_fb_ targets from
> the TODO, which is clearly not the intention in this context.
> 
> Use backslashes to escape the special meaning of the underscore.

Yeah that's one of the things where rst gets a bit in the way of just
plain text. Another one is * at the end ...

Reviewed-by: Daniel Vetter 

> 
> Signed-off-by: Thierry Reding 
> ---
>  Documentation/gpu/todo.rst | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index 1ae42006deea..22af55d06ab8 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -108,8 +108,8 @@ This would be especially useful for tinydrm:
>crtc state, clear that to the max values, x/y = 0 and w/h = MAX_INT, in
>__drm_atomic_helper_crtc_duplicate_state().
>  
> -- Move tinydrm_merge_clips into drm_framebuffer.c, dropping the tinydrm_
> -  prefix ofc and using drm_fb_. drm_framebuffer.c makes sense since this
> +- Move tinydrm_merge_clips into drm_framebuffer.c, dropping the tinydrm\_
> +  prefix ofc and using drm_fb\_. drm_framebuffer.c makes sense since this
>is a function useful to implement the fb->dirty function.
>  
>  - Create a new drm_fb_dirty function which does essentially what e.g.
> -- 
> 2.13.3
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/omap: Rework the rotation-on-crtc hack

[Daniel Vetter]

I want/need to rework the core property handling, and this hack is
getting in the way. But since it's a non-standard propety only used by
legacy userspace we know that this will only every be called from
ioctl code. And never on some other free-standing state struct, where
this old hack wouldn't work either.

v2: don't forget zorder and get_property!

v3: Shadow the legacy state to avoid locking issues in get_property
(Maarten).

v4: Review from Laurent
- Move struct omap_crtc_state into omap_crtc.c
- Clean up comments.
- Don't forget to copy the shadowed state over on duplicate.

Cc: Maarten Lankhorst 
Cc: Tomi Valkeinen 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/omapdrm/omap_crtc.c | 95 +++--
 1 file changed, 59 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 14e8a7738b06..16d8b291921b 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -26,6 +26,16 @@
 
 #include "omap_drv.h"
 
+#define to_omap_crtc_state(x) container_of(x, struct omap_crtc_state, base)
+
+struct omap_crtc_state {
+   /* Must be first. */
+   struct drm_crtc_state base;
+   /* Shadow values for legacy userspace support. */
+   unsigned int rotation;
+   unsigned int zpos;
+};
+
 #define to_omap_crtc(x) container_of(x, struct omap_crtc, base)
 
 struct omap_crtc {
@@ -498,39 +508,35 @@ static void omap_crtc_atomic_flush(struct drm_crtc *crtc,
spin_unlock_irq(>dev->event_lock);
 }
 
-static bool omap_crtc_is_plane_prop(struct drm_crtc *crtc,
-   struct drm_property *property)
-{
-   struct drm_device *dev = crtc->dev;
-   struct omap_drm_private *priv = dev->dev_private;
-
-   return property == priv->zorder_prop ||
-   property == crtc->primary->rotation_property;
-}
-
 static int omap_crtc_atomic_set_property(struct drm_crtc *crtc,
 struct drm_crtc_state *state,
 struct drm_property *property,
 uint64_t val)
 {
-   if (omap_crtc_is_plane_prop(crtc, property)) {
-   struct drm_plane_state *plane_state;
-   struct drm_plane *plane = crtc->primary;
-
-   /*
-* Delegate property set to the primary plane. Get the plane
-* state and set the property directly.
-*/
-
-   plane_state = drm_atomic_get_plane_state(state->state, plane);
-   if (IS_ERR(plane_state))
-   return PTR_ERR(plane_state);
+   struct omap_drm_private *priv = crtc->dev->dev_private;
+   struct omap_crtc_state *omap_state = to_omap_crtc_state(state);
+   struct drm_plane_state *plane_state;
 
-   return drm_atomic_plane_set_property(plane, plane_state,
-   property, val);
+   /*
+* Delegate property set to the primary plane. Get the plane state and
+* set the property directly, but keep a shadow copy for the
+* atomic_get_property callback.
+*/
+   plane_state = drm_atomic_get_plane_state(state->state, crtc->primary);
+   if (IS_ERR(plane_state))
+   return PTR_ERR(plane_state);
+
+   if (property == crtc->primary->rotation_property) {
+   plane_state->rotation = val;
+   omap_state->rotation = val;
+   } else if (property == priv->zorder_prop) {
+   plane_state->zpos = val;
+   omap_state->zpos = val;
+   } else {
+   return -EINVAL;
}
 
-   return -EINVAL;
+   return 0;
 }
 
 static int omap_crtc_atomic_get_property(struct drm_crtc *crtc,
@@ -538,20 +544,37 @@ static int omap_crtc_atomic_get_property(struct drm_crtc 
*crtc,
 struct drm_property *property,
 uint64_t *val)
 {
-   if (omap_crtc_is_plane_prop(crtc, property)) {
-   /*
-* Delegate property get to the primary plane. The
-* drm_atomic_plane_get_property() function isn't exported, but
-* can be called through drm_object_property_get_value() as that
-* will call drm_atomic_get_property() for atomic drivers.
-*/
-   return drm_object_property_get_value(>primary->base,
-   property, val);
-   }
+   struct omap_drm_private *priv = crtc->dev->dev_private;
+   struct omap_crtc_state *omap_state = to_omap_crtc_state(state);
+
+   if (property == crtc->primary->rotation_property)
+   return omap_state->rotation;
+   else if (property == priv->zorder_prop)
+   return 

[PATCH] drm: todo: Avoid accidental crossreferences

[Thierry Reding]

From: Thierry Reding 

RST uses underscores at the end of words to create crossreferences and
it will accidentally try to link to tinydrm_ and drm_fb_ targets from
the TODO, which is clearly not the intention in this context.

Use backslashes to escape the special meaning of the underscore.

Signed-off-by: Thierry Reding 
---
 Documentation/gpu/todo.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 1ae42006deea..22af55d06ab8 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -108,8 +108,8 @@ This would be especially useful for tinydrm:
   crtc state, clear that to the max values, x/y = 0 and w/h = MAX_INT, in
   __drm_atomic_helper_crtc_duplicate_state().
 
-- Move tinydrm_merge_clips into drm_framebuffer.c, dropping the tinydrm_
-  prefix ofc and using drm_fb_. drm_framebuffer.c makes sense since this
+- Move tinydrm_merge_clips into drm_framebuffer.c, dropping the tinydrm\_
+  prefix ofc and using drm_fb\_. drm_framebuffer.c makes sense since this
   is a function useful to implement the fb->dirty function.
 
 - Create a new drm_fb_dirty function which does essentially what e.g.
-- 
2.13.3

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

Re: [PATCH 0/4] drm: Fix some warnings when building docs

[Thierry Reding]

On Thu, Jul 20, 2017 at 01:47:39PM -0400, Sean Paul wrote:
> I noticed these warnings as part of my compile testing and decided to fix 
> them.
> 
> There are still a few warnings with the import/export prime helpers. They're
> partially documented in drm_prime.c, so suggestions welcome on how to resolve
> them without duplication (or perhaps duplication is best in this case).
> 
> Sean
> 
> 
> 
> Sean Paul (4):
>   drm/modes: Fix drm_mode_is_420_only() comment
>   drm: Fix warning when building docs for scdc_helper
>   gpu/host1x: Remove excess parameter in host1x_subdev_add docs
>   drm: Add a few missing descriptions in drm_driver docs
> 
>  drivers/gpu/drm/drm_modes.c   |  2 +-
>  drivers/gpu/drm/drm_scdc_helper.c |  4 +--
>  drivers/gpu/host1x/bus.c  |  1 -
>  include/drm/drm_drv.h | 52 
> ++-
>  4 files changed, 49 insertions(+), 10 deletions(-)

Applied all four patches to drm-misc-next, thanks.

Thierry


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 6/6] drm/rockchip: fix race with kms hotplug and fbdev

[Daniel Vetter]

On Mon, Jul 31, 2017 at 1:57 PM, Emil Velikov  wrote:
> On 31 July 2017 at 10:50, Mark Yao  wrote:
>> Since fb_helper is not a pointer on rockchip_drm_private, it's no
>> need to check pointer.
>>
>> Kms hotplug event may race into fbdev helper initial, and fb_helper->dev
>> may be NULL pointer, that would cause the bug:
>>
>> [0.735411] [0200] *pgd=f6ffe003, *pud=f6ffe003, 
>> *pmd=
>> [0.736156] Internal error: Oops: 9605 [#1] PREEMPT SMP
>> [0.736648] Modules linked in:
>> [0.736930] CPU: 2 PID: 20 Comm: kworker/2:0 Not tainted 4.4.41 #20
>> [0.737480] Hardware name: Rockchip RK3399 Board rev2 (BOX) (DT)
>> [0.738020] Workqueue: events cdn_dp_pd_event_work
>> [0.738447] task: ffc0f21f3100 ti: ffc0f2218000 task.ti: 
>> ffc0f2218000
>> [0.739109] PC is at mutex_lock+0x14/0x44
>> [0.739469] LR is at drm_fb_helper_hotplug_event+0x30/0x114
>> [0.756253] [] mutex_lock+0x14/0x44
>> [0.756260] [] drm_fb_helper_hotplug_event+0x30/0x114
>> [0.756271] [] 
>> rockchip_drm_output_poll_changed+0x18/0x20
>> [0.756280] [] drm_kms_helper_hotplug_event+0x28/0x34
>> [0.756286] [] cdn_dp_pd_event_work+0x394/0x3c4
>> [0.756295] [] process_one_work+0x218/0x3e0
>> [0.756302] [] worker_thread+0x2e8/0x404
>> [0.756308] [] kthread+0xe8/0xf0
>> [0.756316] [] ret_from_fork+0x10/0x40
>>
>> Signed-off-by: Mark Yao 
>> ---
>>  drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c 
>> b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
>> index 81f9548..e6bd0f4 100644
>> --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
>> @@ -170,7 +170,7 @@ static void rockchip_drm_output_poll_changed(struct 
>> drm_device *dev)
>> struct rockchip_drm_private *private = dev->dev_private;
>> struct drm_fb_helper *fb_helper = >fbdev_helper;
>>
>> -   if (fb_helper)
>> +   if (fb_helper->dev)
>> drm_fb_helper_hotplug_event(fb_helper);
> Food for thought:
>
> Quick grep shows that no other drivers have such a ->dev check. Does
> this mean that either the issue is rockchip specific?
> If not, one could look into resolving the problem directly in drm core.
>
> Or at least update the other users, so they don't stumble upon the problem?

The fbdev helpers support already handling hotplug events before you
have finalized the fbdev setup. Please read the kerneldoc for the
various fbdev functions, they explain what you should be doing. This
hack here should indeed not be needed.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] gpu: ipu-v3: add DRM dependency

[Philipp Zabel]

From: Arnd Bergmann 

The new PRE/PRG driver code causes a link failure when IPUv3 is built-in,
but DRM is built as a module:

drivers/gpu/ipu-v3/ipu-pre.o: In function `ipu_pre_configure':
ipu-pre.c:(.text.ipu_pre_configure+0x18): undefined reference to 
`drm_format_info'
drivers/gpu/ipu-v3/ipu-prg.o: In function `ipu_prg_format_supported':
ipu-prg.c:(.text.ipu_prg_format_supported+0x8): undefined reference to 
`drm_format_info'

Adding a Kconfig dependency on DRM means we don't run into this problem
any more. If DRM is disabled altogether, the IPUv3 driver is built
without PRE/PRG support.

Fixes: ea9c260514c1 ("gpu: ipu-v3: add driver for Prefetch Resolve Gasket")
Link: https://patchwork.kernel.org/patch/9636665/
Signed-off-by: Arnd Bergmann 
[p.za...@pengutronix.de: changed the dependency from DRM to DRM || !DRM,
 since the link failure only happens when DRM=m and IPUV3_CORE=y.
 Modified the commit message to reflect this.]
Signed-off-by: Philipp Zabel 
---
 drivers/gpu/ipu-v3/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/ipu-v3/Kconfig b/drivers/gpu/ipu-v3/Kconfig
index 08766c6e7856b..87a20b3dcf7a5 100644
--- a/drivers/gpu/ipu-v3/Kconfig
+++ b/drivers/gpu/ipu-v3/Kconfig
@@ -1,6 +1,7 @@
 config IMX_IPUV3_CORE
tristate "IPUv3 core support"
depends on SOC_IMX5 || SOC_IMX6Q || ARCH_MULTIPLATFORM
+   depends on DRM || !DRM # if DRM=m, this can't be 'y'
select GENERIC_IRQ_CHIP
help
  Choose this if you have a i.MX5/6 system and want to use the Image
-- 
2.11.0

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

Re: [PATCH] drm/omap: Rework the rotation-on-crtc hack

[Laurent Pinchart]

Hi Daniel,

Thank you for the patch.

On Monday 31 Jul 2017 12:54:19 Daniel Vetter wrote:
> I want/need to rework the core property handling, and this hack is
> getting in the way. But since it's a non-standard propety only used by

s/propety/property/

> legacy userspace we know that this will only every be called from
> ioctl code. And never on some other free-standing state struct, where
> this old hack wouldn't work either.
> 
> v2: don't forget zorder and get_property!
> 
> v3: Shadow the legacy state to avoid locking issues in get_property
> (Maarten).
> 
> Cc: Maarten Lankhorst 
> Cc: Tomi Valkeinen  Cc: Laurent Pinchart 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/omapdrm/omap_crtc.c | 84 ++
>  drivers/gpu/drm/omapdrm/omap_drv.h  |  9 
>  2 files changed, 57 insertions(+), 36 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
> b/drivers/gpu/drm/omapdrm/omap_crtc.c index 14e8a7738b06..fc8b25748f10
> 100644
> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
> @@ -498,39 +498,34 @@ static void omap_crtc_atomic_flush(struct drm_crtc
> *crtc, spin_unlock_irq(>dev->event_lock);
>  }
> 
> -static bool omap_crtc_is_plane_prop(struct drm_crtc *crtc,
> - struct drm_property *property)
> -{
> - struct drm_device *dev = crtc->dev;
> - struct omap_drm_private *priv = dev->dev_private;
> -
> - return property == priv->zorder_prop ||
> - property == crtc->primary->rotation_property;
> -}
> -
>  static int omap_crtc_atomic_set_property(struct drm_crtc *crtc,
>struct drm_crtc_state *state,
>struct drm_property *property,
>uint64_t val)
>  {
> - if (omap_crtc_is_plane_prop(crtc, property)) {
> - struct drm_plane_state *plane_state;
> - struct drm_plane *plane = crtc->primary;
> -
> - /*
> -  * Delegate property set to the primary plane. Get the plane
> -  * state and set the property directly.
> -  */
> -
> - plane_state = drm_atomic_get_plane_state(state->state, plane);
> - if (IS_ERR(plane_state))
> - return PTR_ERR(plane_state);
> + struct omap_drm_private *priv = crtc->dev->dev_private;
> + struct omap_crtc_state *omap_state = to_omap_crtc_state(state);
> + struct drm_plane_state *plane_state;
> 
> - return drm_atomic_plane_set_property(plane, plane_state,
> - property, val);
> + /*
> +  * Delegate property set to the primary plane. Get the plane
> +  * state and set the property directly.

Nitpicking, you can reformat the comment to go towards the 80 columns limit.

> +  */
> + plane_state = drm_atomic_get_plane_state(state->state, crtc->primary);
> + if (IS_ERR(plane_state))
> + return PTR_ERR(plane_state);
> +
> + if (property == crtc->primary->rotation_property) {
> + plane_state->rotation = val;
> + omap_state->rotation = val;
> + } else if (property == priv->zorder_prop) {
> + plane_state->zpos = val;
> + omap_state->zpos = val;
> + } else {
> + return -EINVAL;
>   }
> 
> - return -EINVAL;
> + return 0;
>  }
> 
>  static int omap_crtc_atomic_get_property(struct drm_crtc *crtc,
> @@ -538,20 +533,37 @@ static int omap_crtc_atomic_get_property(struct
> drm_crtc *crtc, struct drm_property *property,
>uint64_t *val)
>  {
> - if (omap_crtc_is_plane_prop(crtc, property)) {
> - /*
> -  * Delegate property get to the primary plane. The
> -  * drm_atomic_plane_get_property() function isn't exported, 
but
> -  * can be called through drm_object_property_get_value() as 
that
> -  * will call drm_atomic_get_property() for atomic drivers.
> -  */
> - return drm_object_property_get_value(>primary->base,
> - property, val);
> - }
> + struct omap_drm_private *priv = crtc->dev->dev_private;
> + struct omap_crtc_state *omap_state = to_omap_crtc_state(state);
> +
> + /*
> +  * Remap to the plane rotation/zorder property. We can peek at the 
plane
> +  * state directly since holding the crtc locks gives you a read-lock 
on
> +  * the plane state.

Isn't this comment outdated ?

> +  */
> + if (property == crtc->primary->rotation_property)
> + return omap_state->rotation;
> + else if (property == priv->zorder_prop)
> + return omap_state->zpos;
> 
>   return -EINVAL;
>  }
> 
> +static struct drm_crtc_state *
> +omap_crtc_duplicate_state(struct drm_crtc *crtc)

Re: [PATCH 6/6] drm/rockchip: fix race with kms hotplug and fbdev

[Emil Velikov]

On 31 July 2017 at 10:50, Mark Yao  wrote:
> Since fb_helper is not a pointer on rockchip_drm_private, it's no
> need to check pointer.
>
> Kms hotplug event may race into fbdev helper initial, and fb_helper->dev
> may be NULL pointer, that would cause the bug:
>
> [0.735411] [0200] *pgd=f6ffe003, *pud=f6ffe003, 
> *pmd=
> [0.736156] Internal error: Oops: 9605 [#1] PREEMPT SMP
> [0.736648] Modules linked in:
> [0.736930] CPU: 2 PID: 20 Comm: kworker/2:0 Not tainted 4.4.41 #20
> [0.737480] Hardware name: Rockchip RK3399 Board rev2 (BOX) (DT)
> [0.738020] Workqueue: events cdn_dp_pd_event_work
> [0.738447] task: ffc0f21f3100 ti: ffc0f2218000 task.ti: 
> ffc0f2218000
> [0.739109] PC is at mutex_lock+0x14/0x44
> [0.739469] LR is at drm_fb_helper_hotplug_event+0x30/0x114
> [0.756253] [] mutex_lock+0x14/0x44
> [0.756260] [] drm_fb_helper_hotplug_event+0x30/0x114
> [0.756271] [] rockchip_drm_output_poll_changed+0x18/0x20
> [0.756280] [] drm_kms_helper_hotplug_event+0x28/0x34
> [0.756286] [] cdn_dp_pd_event_work+0x394/0x3c4
> [0.756295] [] process_one_work+0x218/0x3e0
> [0.756302] [] worker_thread+0x2e8/0x404
> [0.756308] [] kthread+0xe8/0xf0
> [0.756316] [] ret_from_fork+0x10/0x40
>
> Signed-off-by: Mark Yao 
> ---
>  drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> index 81f9548..e6bd0f4 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> @@ -170,7 +170,7 @@ static void rockchip_drm_output_poll_changed(struct 
> drm_device *dev)
> struct rockchip_drm_private *private = dev->dev_private;
> struct drm_fb_helper *fb_helper = >fbdev_helper;
>
> -   if (fb_helper)
> +   if (fb_helper->dev)
> drm_fb_helper_hotplug_event(fb_helper);
Food for thought:

Quick grep shows that no other drivers have such a ->dev check. Does
this mean that either the issue is rockchip specific?
If not, one could look into resolving the problem directly in drm core.

Or at least update the other users, so they don't stumble upon the problem?

HTH
Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH for v4.13] ARM: dts: exynos: add needs-hpd for Odroid-XU3/4

[Hans Verkuil]

CEC support was added for Exynos5 in 4.13, but for the Odroids we need to set
'needs-hpd' as well since CEC is disabled when there is no HDMI hotplug signal,
just as for the exynos4 Odroid-U3.

This is due to the level-shifter that is disabled when there is no HPD, thus
blocking the CEC signal as well. Same close-but-no-cigar board design as the
Odroid-U3.

Tested with my Odroid XU4.

Signed-off-by: Hans Verkuil 
---
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 
b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
index f92f95741207..a183b56283f8 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
@@ -266,6 +266,7 @@

  {
status = "okay";
+   needs-hpd;
 };

 _4 {

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

Re: [Intel-gfx] [PATCH 1/8] drm/omap: Simplify the rotation-on-crtc hack

[Tomi Valkeinen]

On 31/07/17 14:48, Laurent Pinchart wrote:

>>> The comment about read lock is only valid when the plane is bound to the
>>> crtc. In general this is not always the case. You can only peak at
>>> plane->state when crtc->state->plane_mask & BIT(drm_plane_index(plane))
>>> is true.
>>>
>>> I think we might need -EDEADLK handling for getprop then, even though it's
>>> not optimal. :(
>>
>> Well both the old an new way only worked because we grab all the locks
>> unconditionally. And I'd really want to avoid get_prop being anything
>> but a simple lookup. Unfortuantely that breaks omapdrm, so no idea
>> what exactly to do here.
>>
>> In a way adding properties without standardizing them across drivers
>> first was a really bad idea, because then we have disjoint sets of
>> uapi expectations, and there's just no way to make that work.
>>
>> I guess one radical approach might be to make this the "standard", and
>> just redirect rotation from the CRTC to the primary plane.
>>
>> Or omapdrm needs to duplicate the property properly, and update one if
>> the other is set. I think that's probably the most workable approach.
> 
> Maybe the first question we should answer is whether this hack is still 
> needed 
> in the omapdrm driver. Tomi, do you know whether userspace still needs this ?

The omap X driver uses legacy modesetting and the rotation property for
the crtc.

 Tomi



signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 1/8] drm/omap: Simplify the rotation-on-crtc hack

[Laurent Pinchart]

Hi Daniel,

On Tuesday 25 Jul 2017 11:24:28 Daniel Vetter wrote:
> On Tue, Jul 25, 2017 at 10:47 AM, Maarten Lankhorst wrote:
> > Op 25-07-17 om 10:01 schreef Daniel Vetter:
> >> I want/need to rework the core property handling, and this hack is
> >> getting in the way. But since it's a non-standard propety only used by
> >> legacy userspace we know that this will only every be called from
> >> ioctl code. And never on some other free-standing state struct, where
> >> this old hack wouldn't work either.
> >> 
> >> v2: don't forget zorder and get_property!
> >> 
> >> Cc: Tomi Valkeinen  >> Cc: Laurent Pinchart 
> >> Signed-off-by: Daniel Vetter 
> >> ---
> >> 
> >>  drivers/gpu/drm/omapdrm/omap_crtc.c | 64 ++-
> >>  1 file changed, 28 insertions(+), 36 deletions(-)

[snip]

> > The comment about read lock is only valid when the plane is bound to the
> > crtc. In general this is not always the case. You can only peak at
> > plane->state when crtc->state->plane_mask & BIT(drm_plane_index(plane))
> > is true.
> > 
> > I think we might need -EDEADLK handling for getprop then, even though it's
> > not optimal. :(
>
> Well both the old an new way only worked because we grab all the locks
> unconditionally. And I'd really want to avoid get_prop being anything
> but a simple lookup. Unfortuantely that breaks omapdrm, so no idea
> what exactly to do here.
> 
> In a way adding properties without standardizing them across drivers
> first was a really bad idea, because then we have disjoint sets of
> uapi expectations, and there's just no way to make that work.
> 
> I guess one radical approach might be to make this the "standard", and
> just redirect rotation from the CRTC to the primary plane.
> 
> Or omapdrm needs to duplicate the property properly, and update one if
> the other is set. I think that's probably the most workable approach.

Maybe the first question we should answer is whether this hack is still needed 
in the omapdrm driver. Tomi, do you know whether userspace still needs this ?

-- 
Regards,

Laurent Pinchart

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

[Bug 101961] Serious Sam Fusion hangs system completely

[bugzilla-daemon]

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

--- Comment #5 from network...@rkmail.ru ---
(In reply to Samuel Pitoiset from comment #4)
> It looks weird, but can you try reverting 5c1241268b ?

reverting 5c1241268b helps, no hangs so far.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 0/3] Kconfig dependencies: acpi-video, backlight and thermal

[Jani Nikula]

On Wed, 26 Jul 2017, Daniel Vetter  wrote:
> On Wed, Jul 26, 2017 at 03:53:09PM +0200, Arnd Bergmann wrote:
>> Hi everyone,
>> 
>> It took me a while to figure this out properly, as I kept getting
>> circular or missing dependencies with video drivers.
>> 
>> This set of three patches should simplify the situation a bit,
>> mostly by cleaning up the dependencies around CONFIG_ACPI_VIDEO.
>> With all three patches applied, I no longer run into those related
>> warnings. If everyone agrees on the general direction, I hope
>> we can merge all three through the DRM tree.
>> 
>> I originally had another larger patch in the series to replace all
>> of the 'select BACKLIGHT_LCD_SUPPORT; select BACKLIGHT_CLASS_DEVICE'
>> statements with 'depends on LCD_CLASS_DEVICE', that would clean
>> it up some more, but it is also a more invasive change that we
>> can do separately at some point.
>
> Looks reasonable, but I think it'd be good to get Jani Nikula's explicit
> ack on this, since he dugg around a lot in this area. And he's on vacation
> this week.

I didn't dig through all the details, but looks good to me and
definitely an improvement in drm Kconfigs.

Acked-by: Jani Nikula 



> -Daniel
>
>> 
>>Arnd
>> 
>> Arnd Bergmann (3):
>>   backlight: always select BACKLIGHT_LCD_SUPPORT for
>> BACKLIGHT_CLASS_DEVICE
>>   ACPI/DRM: rework ACPI_VIDEO Kconfig dependencies
>>   drm/etnaviv: add thermal dependency
>> 
>>  drivers/acpi/Kconfig  |  7 +--
>>  drivers/gpu/drm/etnaviv/Kconfig   |  1 +
>>  drivers/gpu/drm/gma500/Kconfig|  5 +
>>  drivers/gpu/drm/i915/Kconfig  |  7 +--
>>  drivers/gpu/drm/nouveau/Kconfig   | 10 ++
>>  drivers/platform/x86/Kconfig  |  9 -
>>  drivers/staging/olpc_dcon/Kconfig |  1 +
>>  7 files changed, 15 insertions(+), 25 deletions(-)
>> 
>> To: dri-devel@lists.freedesktop.org
>> Cc: "Rafael J. Wysocki" 
>> Cc: Len Brown 
>> Cc: Lucas Stach 
>> Cc: Russell King 
>> Cc: Christian Gmeiner 
>> Cc: David Airlie 
>> Cc: Patrik Jakobsson 
>> Cc: Daniel Vetter 
>> Cc: Jani Nikula 
>> Cc: Ben Skeggs 
>> Cc: Darren Hart 
>> Cc: Andy Shevchenko 
>> Cc: Jens Frederich 
>> Cc: Daniel Drake 
>> Cc: Jon Nettleton 
>> Cc: Greg Kroah-Hartman 
>> Cc: linux-a...@vger.kernel.org
>> Cc: linux-ker...@vger.kernel.org
>> Cc: etna...@lists.freedesktop.org
>> Cc: intel-...@lists.freedesktop.org
>> Cc: nouv...@lists.freedesktop.org
>> Cc: platform-driver-...@vger.kernel.org
>> Cc: de...@driverdev.osuosl.org
>> 
>> -- 
>> 2.9.0
>> 
>> ___
>> Intel-gfx mailing list
>> intel-...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: Fix kerneldoc for atomic_async_update

[Daniel Vetter]

The enumeration of FIXMEs wasn't indented properly.

Fixes: fef9df8b5945 ("drm/atomic: initial support for asynchronous plane 
update")
Cc: Gustavo Padovan 
Signed-off-by: Daniel Vetter 
---
 include/drm/drm_modeset_helper_vtables.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/drm/drm_modeset_helper_vtables.h 
b/include/drm/drm_modeset_helper_vtables.h
index 06569845708c..810c2aae9d81 100644
--- a/include/drm/drm_modeset_helper_vtables.h
+++ b/include/drm/drm_modeset_helper_vtables.h
@@ -1179,9 +1179,9 @@ struct drm_plane_helper_funcs {
 *  - It only works for single plane updates
 *  - Async Pageflips are not supported yet
 *  - Some hw might still scan out the old buffer until the next
-*  vblank, however we let go of the fb references as soon as
-*  we run this hook. For now drivers must implement their own workers
-*  for deferring if needed, until a common solution is created.
+*vblank, however we let go of the fb references as soon as
+*we run this hook. For now drivers must implement their own workers
+*for deferring if needed, until a common solution is created.
 */
void (*atomic_async_update)(struct drm_plane *plane,
struct drm_plane_state *new_state);
-- 
2.9.4

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

[PATCH] drm/omap: Rework the rotation-on-crtc hack

[Daniel Vetter]

I want/need to rework the core property handling, and this hack is
getting in the way. But since it's a non-standard propety only used by
legacy userspace we know that this will only every be called from
ioctl code. And never on some other free-standing state struct, where
this old hack wouldn't work either.

v2: don't forget zorder and get_property!

v3: Shadow the legacy state to avoid locking issues in get_property
(Maarten).

Cc: Maarten Lankhorst 
Cc: Tomi Valkeinen 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/omapdrm/omap_crtc.c | 84 +
 drivers/gpu/drm/omapdrm/omap_drv.h  |  9 
 2 files changed, 57 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 14e8a7738b06..fc8b25748f10 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -498,39 +498,34 @@ static void omap_crtc_atomic_flush(struct drm_crtc *crtc,
spin_unlock_irq(>dev->event_lock);
 }
 
-static bool omap_crtc_is_plane_prop(struct drm_crtc *crtc,
-   struct drm_property *property)
-{
-   struct drm_device *dev = crtc->dev;
-   struct omap_drm_private *priv = dev->dev_private;
-
-   return property == priv->zorder_prop ||
-   property == crtc->primary->rotation_property;
-}
-
 static int omap_crtc_atomic_set_property(struct drm_crtc *crtc,
 struct drm_crtc_state *state,
 struct drm_property *property,
 uint64_t val)
 {
-   if (omap_crtc_is_plane_prop(crtc, property)) {
-   struct drm_plane_state *plane_state;
-   struct drm_plane *plane = crtc->primary;
-
-   /*
-* Delegate property set to the primary plane. Get the plane
-* state and set the property directly.
-*/
-
-   plane_state = drm_atomic_get_plane_state(state->state, plane);
-   if (IS_ERR(plane_state))
-   return PTR_ERR(plane_state);
+   struct omap_drm_private *priv = crtc->dev->dev_private;
+   struct omap_crtc_state *omap_state = to_omap_crtc_state(state);
+   struct drm_plane_state *plane_state;
 
-   return drm_atomic_plane_set_property(plane, plane_state,
-   property, val);
+   /*
+* Delegate property set to the primary plane. Get the plane
+* state and set the property directly.
+*/
+   plane_state = drm_atomic_get_plane_state(state->state, crtc->primary);
+   if (IS_ERR(plane_state))
+   return PTR_ERR(plane_state);
+
+   if (property == crtc->primary->rotation_property) {
+   plane_state->rotation = val;
+   omap_state->rotation = val;
+   } else if (property == priv->zorder_prop) {
+   plane_state->zpos = val;
+   omap_state->zpos = val;
+   } else {
+   return -EINVAL;
}
 
-   return -EINVAL;
+   return 0;
 }
 
 static int omap_crtc_atomic_get_property(struct drm_crtc *crtc,
@@ -538,20 +533,37 @@ static int omap_crtc_atomic_get_property(struct drm_crtc 
*crtc,
 struct drm_property *property,
 uint64_t *val)
 {
-   if (omap_crtc_is_plane_prop(crtc, property)) {
-   /*
-* Delegate property get to the primary plane. The
-* drm_atomic_plane_get_property() function isn't exported, but
-* can be called through drm_object_property_get_value() as that
-* will call drm_atomic_get_property() for atomic drivers.
-*/
-   return drm_object_property_get_value(>primary->base,
-   property, val);
-   }
+   struct omap_drm_private *priv = crtc->dev->dev_private;
+   struct omap_crtc_state *omap_state = to_omap_crtc_state(state);
+
+   /*
+* Remap to the plane rotation/zorder property. We can peek at the plane
+* state directly since holding the crtc locks gives you a read-lock on
+* the plane state.
+*/
+   if (property == crtc->primary->rotation_property)
+   return omap_state->rotation;
+   else if (property == priv->zorder_prop)
+   return omap_state->zpos;
 
return -EINVAL;
 }
 
+static struct drm_crtc_state *
+omap_crtc_duplicate_state(struct drm_crtc *crtc)
+{
+   struct omap_crtc_state *state;
+
+   if (WARN_ON(!crtc->state))
+   return NULL;
+
+   state = kmalloc(sizeof(*state), GFP_KERNEL);
+   if (state)
+   __drm_atomic_helper_crtc_duplicate_state(crtc, >base);
+
+   return 

Re: [PATCH] drm/atomic: Update comment to match the code

[Daniel Vetter]

On Mon, Jul 31, 2017 at 11:13:43AM +0200, Thierry Reding wrote:
> From: Thierry Reding 
> 
> The kerneldoc for drm_atomic_crtc_needs_modeset() is outdated and no
> longer reflects the actual code. Fix that up to remove confusion.
> 
> Signed-off-by: Thierry Reding 

Reviewed-by: Daniel Vetter 

Pls push to drm-misc-next.
-Daniel

> ---
>  include/drm/drm_atomic.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
> index 7cd0f303f5a3..a7adbf57b886 100644
> --- a/include/drm/drm_atomic.h
> +++ b/include/drm/drm_atomic.h
> @@ -883,7 +883,7 @@ void drm_state_dump(struct drm_device *dev, struct 
> drm_printer *p);
>   *
>   * To give drivers flexibility  drm_crtc_state has 3 booleans to track
>   * whether the state CRTC changed enough to need a full modeset cycle:
> - * planes_changed, mode_changed and active_changed. This helper simply
> + * mode_changed, active_changed and connectors_changed. This helper simply
>   * combines these three to compute the overall need for a modeset for @state.
>   *
>   * The atomic helper code sets these booleans, but drivers can and should
> -- 
> 2.13.3
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel