Re: [PATCH 3/5] drm/virtio: Return an error from connector dpms callback

On Thu, 27 Jul 2017 10:25:24 +0200, Daniel Vetter wrote: > > On Thu, Jul 27, 2017 at 10:22 AM, Takashi Iwai wrote: > > On Thu, 27 Jul 2017 08:52:48 +0200, > > Daniel Vetter wrote: > >> > >> On Wed, Jul 26, 2017 at 10:56:34PM +0200, Takashi Iwai wrote: > >> > The virtio drm driver

Re: [PATCH v6 4/7] drm/rockchip: vop: group vop registers

Am Donnerstag, 27. Juli 2017, 11:51:06 CEST schrieb Heiko Stübner: > Hi Mark, > > Am Mittwoch, 26. Juli 2017, 14:19:25 CEST schrieb Mark Yao: > > Grouping the vop registers facilitates make register > > definition clearer, and also is useful for different vop > > reuse the same group register. >

Re: [PATCH 17/41] drm/sun4i: Use .dumb_map_offset and .dumb_destroy defaults

On Sun, Jul 23, 2017 at 09:16:33PM +0200, Noralf Trønnes wrote: > This driver can use the drm_driver.dumb_destroy and > drm_driver.dumb_map_offset defaults, so no need to set them. > > Cc: Maxime Ripard > Signed-off-by: Noralf Trønnes > ---

Re: [v6,1/7] drm/rockchip: vop: initialize registers directly

Hi mark, On 07/26/2017 02:19 PM, Mark yao wrote: At present we are using init_table to initialize some registers, but the Register init table use un-document define, it is unreadable, and sometimes we only want to update tiny bits, init table method is not friendly, it's diffcult to reuse for

Re: [PATCH v6 4/7] drm/rockchip: vop: group vop registers

Hi Mark, Am Mittwoch, 26. Juli 2017, 14:19:25 CEST schrieb Mark Yao: > Grouping the vop registers facilitates make register > definition clearer, and also is useful for different vop > reuse the same group register. > > Signed-off-by: Mark Yao > --- >

Re: [v6,7/7] drm/rockchip: vop: rk3328: fix overlay abnormal

Hi mark, On 07/26/2017 02:19 PM, Mark yao wrote: It's a hardware bug, all window's overlay channel reset value is same, hardware overlay would be die. so we must initial difference id for each overlay channel. The Channel register is supported on all vop will full design. Following is the

Re: [v6, 2/7] drm/rockchip: vop: move write_relaxed flags to vop register

Hi mark, On 07/26/2017 02:19 PM, Mark yao wrote: Since the drm atomic framework, only a small part of the vop register needs sync write, Currently seems only following registers need sync write: cfg_done, standby and interrupt related register. All ctrl registers are using the sync write

Re: [PATCH 3/5] drm/virtio: Return an error from connector dpms callback

On Thu, 27 Jul 2017 08:52:48 +0200, Daniel Vetter wrote: > > On Wed, Jul 26, 2017 at 10:56:34PM +0200, Takashi Iwai wrote: > > The virtio drm driver doesn't treat with DPMS, so we should return an > > error from the connector dpms callback so that the fbcon can fall back > > to the generic blank

Re: [PATCH 01/41] drm/gem: Add drm_gem_dumb_map_offset()

Hi Noralf, On Wednesday 26 Jul 2017 20:41:53 Noralf Trønnes wrote: > Den 26.07.2017 14.05, skrev Emil Velikov: > > On 23 July 2017 at 20:16, Noralf Trønnes wrote: > >> Add a common drm_driver.dumb_map_offset function for GEM backed drivers. > >> > >> Signed-off-by: Noralf

[PATCH libdrm v2 2/2] android: amdgpu: fix build break

Define two macros to avoid building errors. Fixes: 7e6bf88cac (amdgpu: move asic id table to a separate file) Signed-off-by: Chih-Wei Huang --- amdgpu/Android.mk | 6 ++ 1 file changed, 6 insertions(+) diff --git a/amdgpu/Android.mk b/amdgpu/Android.mk index

[PATCH libdrm v2 1/2] android: add rules to build amdgpu.ids

Signed-off-by: Chih-Wei Huang --- data/Android.mk | 9 + 1 file changed, 9 insertions(+) create mode 100644 data/Android.mk diff --git a/data/Android.mk b/data/Android.mk new file mode 100644 index 000..3c1fd7c --- /dev/null +++ b/data/Android.mk @@ -0,0 +1,9

Re: [v6,5/7] drm/rockchip: vop: add a series of vop support

Hi mark, On 07/26/2017 02:19 PM, Mark yao wrote: Vop Full framework now has following vops: IP versionchipname 3.1 rk3288 3.2 rk3368 3.4 rk3366 3.5 rk3399 big 3.6 rk3399 lit 3.7 rk3228 3.8 rk3328 The

Re: [PATCH 3/5] drm/virtio: Return an error from connector dpms callback

On Wed, Jul 26, 2017 at 10:56:34PM +0200, Takashi Iwai wrote: > The virtio drm driver doesn't treat with DPMS, so we should return an > error from the connector dpms callback so that the fbcon can fall back > to the generic blank mode. > > Signed-off-by: Takashi Iwai > --- >

Re: [PATCH v2 09/12] drm/tilcdc: Handle drm_atomic_helper_swap_state failure

On 07/11/17 17:33, Maarten Lankhorst wrote: > drm_atomic_helper_swap_state() will be changed to interruptible waiting > in the next few commits, so all drivers have to be changed to handling > failure. > > Signed-off-by: Maarten Lankhorst > Cc: Jyri Sarha

Re: [PATCH v3 0/3] Add support for the otm8009a dsi panel

Hi Thierry, The 2 dt-bindings patches have been "acked" by Rob. The driver itself has been "reviewed" two times by Andrzej. Do not hesitate to send me any comments so I can take them into account before my holidays (end of next week)... Many thanks for your support, Philippe :-) On

Re: [PATCH 3/5] drm/virtio: Return an error from connector dpms callback

On Thu, Jul 27, 2017 at 10:22 AM, Takashi Iwai wrote: > On Thu, 27 Jul 2017 08:52:48 +0200, > Daniel Vetter wrote: >> >> On Wed, Jul 26, 2017 at 10:56:34PM +0200, Takashi Iwai wrote: >> > The virtio drm driver doesn't treat with DPMS, so we should return an >> > error from the

[PATCH] tinydrm: repaper: add CONFIG_THERMAL dependency

The new RePaper driver uses the thermal subsystem, and fails to link when it is built-in but thermal is a loadable module: drivers/gpu/drm/tinydrm/repaper.o: In function `repaper_probe': repaper.c:(.text+0x540): undefined reference to `thermal_zone_get_zone_by_name'

Re: [PATCH 1/5] drm: Propagate error from connector dpms function in drm_fb_helper_blank()

On Wed, Jul 26, 2017 at 10:56:32PM +0200, Takashi Iwai wrote: > Currently the DRM fbcon helper for console blank, > drm_fb_helper_blank(), simply calls drm_fb_helper_dpms() and always > returns zero, supposing the driver dealing with DPMS properly for > blanking the screen. However, it turned out

Re: [PATCH 2/5] drm/bochs: Return an error from connector dpms callback

On Wed, Jul 26, 2017 at 10:56:33PM +0200, Takashi Iwai wrote: > The bochs drm driver doesn't treat with DPMS, so we should return an > error from the connector dpms callback so that the fbcon can fall back > to the generic blank mode. > > Signed-off-by: Takashi Iwai > --- >

Re: [v6,4/7] drm/rockchip: vop: group vop registers

Hi mark, On 07/26/2017 02:19 PM, Mark yao wrote: Grouping the vop registers facilitates make register definition clearer, and also is useful for different vop reuse the same group register. Signed-off-by: Mark Yao Reviewed-by: Jeffy Chen

Re: [PATCH] android: amdgpu: move asic id table to a separate file

> 2017-07-26 17:27 GMT+02:00 Emil Velikov : >> On 25 July 2017 at 08:28, Chih-Wei Huang wrote: >>> Hi Mauro, >>> Please note AMDGPU_ASIC_ID_TABLE >>> should be a path in the target device (i.e., Android). >>> So using $(LIBDRM_TOP) is incorrect.

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

On 27/07/17 11:34, Jyri Sarha wrote: On 07/17/17 17:02, srinivas.kandaga...@linaro.org wrote: 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

[PATCH 4/6] drm/bridge: tc358767: fix timing calculations

Fields in HTIM01 and HTIM02 regs should be even. Recomended thresh_dly value is max_tu_symbol. Signed-off-by: Andrey Gusakov --- drivers/gpu/drm/bridge/tc358767.c | 34 -- 1 file changed, 20 insertions(+), 14 deletions(-) diff

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

This set of patches fixes several issues that was found during testing tc358767 with desktop DisplayPort displays. 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

[PATCH 2/6] drm/bridge: tc358767: filter out too high modes

Minimum pixel clock period is 6.5 nS for DPI. Do not accept modes with lower pixel clock period. Signed-off-by: Andrey Gusakov --- drivers/gpu/drm/bridge/tc358767.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git

[PATCH 3/6] drm/bridge: tc358767: fix DP0_MISC register set

Remove shift from TU_SIZE_RECOMMENDED define as it used to calculate max_tu_symbols. Signed-off-by: Andrey Gusakov --- drivers/gpu/drm/bridge/tc358767.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/bridge/tc358767.c

[PATCH 6/6] drm/bridge: tc358767: fix 1-lane behavior

Use drm_dp_channel_eq_ok helper Signed-off-by: Andrey Gusakov --- drivers/gpu/drm/bridge/tc358767.c | 13 +++-- 1 file changed, 3 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/tc358767.c index

Re: [PATCH] drm/bridge: tc358767: fix probe without attached output node

Hi, On Mon, Jul 10, 2017 at 3:41 PM, Lucas Stach wrote: > The output node of the TC358767 is only used if another bridge is chained > behind it. Panels attached to the TC358767 can be detected using the usual > DP AUX probing. This restores the old behavior of ignoring

[PATCH] dim: Continue also for dry runs

It's a bit silly to have to spec both -d and -f to see what dim would all complain about. And dry-run should never cause bad side-effects. Signed-off-by: Daniel Vetter --- dim | 2 ++ 1 file changed, 2 insertions(+) diff --git a/dim b/dim index

[PATCH 5/6] drm/bridge: tc358767: fix AUXDATAn registers access

First four bytes should go to DP0_AUXWDATA0. Due to bug if len > 4 first four bytes was writen to DP0_AUXWDATA1 and all data get shifted by 4 bytes. Fix it. Signed-off-by: Andrey Gusakov --- drivers/gpu/drm/bridge/tc358767.c | 2 +- 1 file changed, 1

[PATCH 1/6] drm/bridge: tc358767: do no fail on hi-res displays

Do not fail data rates higher than 2.7 and more than 2 lanes. Try to fall back to 2.7Gbps and 2 lanes. Signed-off-by: Andrey Gusakov --- drivers/gpu/drm/bridge/tc358767.c | 14 +- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git

[PATCH 2/5] drm/atomic: Convert atomic ioctl locking to interruptible.

Pass DRM_MODESET_ACQUIRE_INTERRUPTIBLE to acquire_init, and handle drm_modeset_backoff which can now fail by returning the error. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/drm_atomic.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-)

[PATCH 1/5] drm/atomic: Prepare drm_modeset_lock infrastructure for interruptible waiting

When we want to make drm_atomic_commit interruptible, there are a lot of places that call the lock function, which we don't have control over. Rather than trying to convert every single one, it's easier to toggle interruptible waiting per acquire_ctx. If drm_modeset_acquire_init is called with

[PATCH 3/5] drm/atomic: Convert pageflip ioctl locking to interruptible.

Pass DRM_MODESET_ACQUIRE_INTERRUPTIBLE to acquire_init, and handle drm_modeset_backoff which can now fail by returning the error. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/drm_plane.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-)

[PATCH 4/5] drm/legacy: Convert cursor ioctl locking to interruptible.

Pass DRM_MODESET_ACQUIRE_INTERRUPTIBLE to acquire_init, and handle drm_modeset_backoff which can now fail by returning the error. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/drm_plane.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-)

[Bug 101946] Rebinding AMDGPU causes initialization errors [R9 290 / 4.10 kernel]

https://bugs.freedesktop.org/show_bug.cgi?id=101946 Robin changed: What|Removed |Added CC||bea...@oscp.info

[Bug 101946] Rebinding AMDGPU causes initialization errors [R9 290 / 4.10 kernel]

https://bugs.freedesktop.org/show_bug.cgi?id=101946 --- Comment #2 from Robin --- Created attachment 133070 --> https://bugs.freedesktop.org/attachment.cgi?id=133070=edit kern.log -- You are receiving this mail because: You are the assignee for the

[Bug 101946] Rebinding AMDGPU causes initialization errors [R9 290 / 4.10 kernel]

https://bugs.freedesktop.org/show_bug.cgi?id=101946 --- Comment #1 from Robin --- Created attachment 133069 --> https://bugs.freedesktop.org/attachment.cgi?id=133069=edit Script output -- You are receiving this mail because: You are the assignee for the

Re: [PATCH 18/41] drm/tilcdc: Use .dumb_map_offset and .dumb_destroy defaults

On 07/23/17 22:16, Noralf Trønnes wrote: > This driver can use the drm_driver.dumb_destroy and > drm_driver.dumb_map_offset defaults, so no need to set them. > > Cc: Jyri Sarha > Cc: Tomi Valkeinen > Signed-off-by: Noralf Trønnes

Re: [PATCH v2 09/12] drm/tilcdc: Handle drm_atomic_helper_swap_state failure

Op 27-07-17 om 09:49 schreef Jyri Sarha: > On 07/11/17 17:33, Maarten Lankhorst wrote: >> drm_atomic_helper_swap_state() will be changed to interruptible waiting >> in the next few commits, so all drivers have to be changed to handling >> failure. >> >> Signed-off-by: Maarten Lankhorst

[Bug 101946] Rebinding AMDGPU causes initialization errors [R9 290 / 4.10 kernel]

https://bugs.freedesktop.org/show_bug.cgi?id=101946 --- Comment #3 from Robin --- What I noticed from the kern.log is that it seems to try and skip init steps the second time amdgpu loads. So perhaps the unbind doesn't do a clean enough shutdown or there may be a bug in the

[PATCH 0/5] drm/atomic: Interruptible locks for everyone!

drm_atomic_commit could previous have always failed when waits failed, but locking was always done uninterruptibly. Add infrastructure to make it possible for callers to choose interruptible locking, and convert the 4 most common ioctl's to use it. All other atomic helpers can be converted when

[PATCH 5/5] drm/legacy: Convert setplane ioctl locking to interruptible.

Pass DRM_MODESET_ACQUIRE_INTERRUPTIBLE to acquire_init, and handle drm_modeset_backoff which can now fail by returning the error. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/drm_plane.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-)

[Bug 101946] Rebinding AMDGPU causes initialization errors [R9 290 / 4.10 kernel]

https://bugs.freedesktop.org/show_bug.cgi?id=101946 Bug ID: 101946 Summary: Rebinding AMDGPU causes initialization errors [R9 290 / 4.10 kernel] Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS:

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

On 07/17/17 17:02, srinivas.kandaga...@linaro.org wrote: > 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

Re: [PATCH 3/5] drm/atomic: Convert pageflip ioctl locking to interruptible.

On Thu, Jul 27, 2017 at 02:58:38PM +0200, Maarten Lankhorst wrote: > Pass DRM_MODESET_ACQUIRE_INTERRUPTIBLE to acquire_init, and handle > drm_modeset_backoff which can now fail by returning the error. > > Signed-off-by: Maarten Lankhorst Same comment as the

Re: [PATCH 0/5] drm/atomic: Interruptible locks for everyone!

Hi Maarten On 27 July 2017 at 13:58, Maarten Lankhorst wrote: > drm_atomic_commit could previous have always failed when waits failed, > but locking was always done uninterruptibly. Add infrastructure to make > it possible for callers to choose interruptible

[Bug 101672] radeonsi: 3D engines causing frequent GPU lockups

https://bugs.freedesktop.org/show_bug.cgi?id=101672 --- Comment #18 from MirceaKitsune --- I used 'dmesg -w' via SSH to monitor dmesg output as the system froze. I have not seen anything of interest, and no new messages were printed before the crash took

Re: [PATCH v2 2/4] drm/i915: Re-register PMIC bus access notifier on runtime resume

On Thu, Jul 06, 2017 at 09:24:48PM +0200, Hans de Goede wrote: > intel_uncore_suspend() unregisters the uncore code's PMIC bus access > notifier and gets called on both normal and runtime suspend. > > intel_uncore_resume_early() re-registers the notifier, but only on > normal resume. Add a new

Re: [PATCH v2 1/4] drm/i915: Fix false-positive assert_rpm_wakelock_held in i915_pmic_bus_access_notifier

Hi, On Thu, Jul 06, 2017 at 09:24:47PM +0200, Hans de Goede wrote: > assert_rpm_wakelock_held is triggered from i915_pmic_bus_access_notifier > even though it gets unregistered on (runtime) suspend, this is caused > by a race happening under the following circumstances: > > intel_runtime_pm_put

[Bug 101946] Rebinding AMDGPU causes initialization errors [R9 290 / 4.10 kernel]

https://bugs.freedesktop.org/show_bug.cgi?id=101946 --- Comment #5 from Alex Deucher --- Created attachment 133075 --> https://bugs.freedesktop.org/attachment.cgi?id=133075=edit possible fix 2/2 -- You are receiving this mail because: You are the assignee for the

[Bug 101946] Rebinding AMDGPU causes initialization errors [R9 290 / 4.10 kernel]

https://bugs.freedesktop.org/show_bug.cgi?id=101946 --- Comment #4 from Alex Deucher --- Created attachment 133074 --> https://bugs.freedesktop.org/attachment.cgi?id=133074=edit possible fix 1/2 Do the attached patches help (based on my drm-next-4.14-wip branch)? --

[Bug 101954] WARNING: suspicious RCU usage in amdgpu_bo_list_get

https://bugs.freedesktop.org/show_bug.cgi?id=101954 Bug ID: 101954 Summary: WARNING: suspicious RCU usage in amdgpu_bo_list_get Product: DRI Version: unspecified Hardware: Other OS: All Status: NEW

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

https://bugs.freedesktop.org/show_bug.cgi?id=99553 Jan Vesely changed: What|Removed |Added Depends on||101952 Referenced

Re: [PATCH v2 3/4] drm/i915: Call uncore_suspend before platform suspend handlers

On Thu, Jul 06, 2017 at 09:24:49PM +0200, Hans de Goede wrote: > Quoting Ville: "the forcewake timer might still be active until the uncore > suspend, and having active forcewakes while we've already told the GT wake > stuff to stop acting normally doesn't seem quite right to me." > >

Re: [Intel-gfx] [PATCH 2/5] drm/atomic: Convert atomic ioctl locking to interruptible.

On Thu, Jul 27, 2017 at 02:58:37PM +0200, Maarten Lankhorst wrote: > Pass DRM_MODESET_ACQUIRE_INTERRUPTIBLE to acquire_init, and > handle drm_modeset_backoff which can now fail by returning the error. > > Signed-off-by: Maarten Lankhorst Requires a testcase,

[pull] radeon and amdgpu drm-next-4.14

Hi Dave, New features for 4.14: - Stop reprogramming the MC, the vbios already does this in asic_init - Reduce internal gart to 256M (this does not affect the ttm GTT pool size) - Initial support for huge pages - Rework bo migration logic - Lots of improvements for vega10 - Powerplay fixes -

Re: [PATCH 1/5] drm/atomic: Prepare drm_modeset_lock infrastructure for interruptible waiting

On Thu, Jul 27, 2017 at 02:58:36PM +0200, Maarten Lankhorst wrote: > When we want to make drm_atomic_commit interruptible, there are a lot of > places that call the lock function, which we don't have control over. > > Rather than trying to convert every single one, it's easier to toggle >

Re: [PATCH 0/5] drm/atomic: Interruptible locks for everyone!

On Thu, Jul 27, 2017 at 03:45:11PM +0100, Emil Velikov wrote: > Hi Maarten > > On 27 July 2017 at 13:58, Maarten Lankhorst > wrote: > > drm_atomic_commit could previous have always failed when waits failed, > > but locking was always done uninterruptibly. Add

Re: [PATCH 01/41] drm/gem: Add drm_gem_dumb_map_offset()

Den 27.07.2017 02.13, skrev Emil Velikov: On 26 July 2017 at 19:41, Noralf Trønnes wrote: Den 26.07.2017 14.05, skrev Emil Velikov: Hi Noralf, On 23 July 2017 at 20:16, Noralf Trønnes wrote: Add a common drm_driver.dumb_map_offset function for GEM

[PATCH 07/17] drm/msm: Add A5XX hardware fault detection

The A5XX GPU has really good hardware fault detection that can detect a abnormal hardware condition and fire an interrupt in a matter of milliseconds which is a lot better than waiting for the hangcheck timer. Enable the interrupt and log information before kicking off recovery. Signed-off-by:

[PATCH 01/17] drm/msm: Remove some potentially blocked register ranges

The 0xf400 and 0xf800 ranges are in the RBBM_SECVID block which may be protected from CPU access. Skip dumping them since they are minimally useful for debugging and they aren't worth a system hang. Signed-off-by: Jordan Crouse --- drivers/gpu/drm/msm/adreno/a5xx_gpu.c |

[PATCH 12/17] drm/msm: Move memptrs to msm_gpu

When we move to multiple ringbuffers we're going to store the data in the memptrs on a per-ring basis. In order to prepare for that move the current memptrs from the adreno namespace into msm_gpu. This is way cleaner and immediately lets us kill off some sub functions so there is much less cost

[PATCH 05/17] drm/msm: args->fence should be args->flags

Fix a typo in msm_ioctl_gem_submit - check args->flags for the MSM_SUBMIT_NO_IMPLICIT flag instead of args->fence. Signed-off-by: Jordan Crouse --- drivers/gpu/drm/msm/msm_gem_submit.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 09/17] drm/msm: Implement per-submitqueue fences

Currently we use a single fence context for the entire GPU. That works until we start dealing with multiple ringbuffers that will all need their own sequence number. So in order for the user to continue using the fence functions we will need some way to uniquely identify a submission that gets

[PATCH 02/17] drm/msm: Allow hardware clock gating to be toggled

There are some use cases wherein we need to turn off hardware clock gating before reading certain registers. Modify the A5XX HWCG function to allow user to enable or disable clock gating at will. Signed-off-by: Jordan Crouse --- drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 42

[PATCH 00/17] drm/msm: GPU fixes and features for 4.14

Here is my stack of Adreno GPU goodness for 4.14. Starting off with a few fixes that could be appropriate for 4.13 if you deem them so and then moving into some new features: - a5xx hardware fault detection - can detect a legitimate fault within microseconds and fires an interrupt so you

[PATCH 03/17] drm/msm: Turn off hardware clock gating before reading A5XX registers

On A5XX GPU hardware clock gating needs to be turned off before reading certain GPU registers via AHB. Turn off HWCG before calling adreno_show() to safely dump all the registers without a system hang. Signed-off-by: Jordan Crouse ---

[PATCH 11/17] drm/msm: Add a helper function for in-kernel buffer allocations

Nearly all of the buffer allocations for kernel allocate an buffer object, virtual address and GPU iova at the same time. Make a helper function to handle the details. Signed-off-by: Jordan Crouse --- drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 22 +++-

[PATCH 17/17] drm/msm: Implement preemption for A5XX targets

Implement preemption for A5XX targets - this allows multiple ringbuffers for different priorities with automatic preemption of a lower priority ringbuffer if a higher one is ready. Signed-off-by: Jordan Crouse --- drivers/gpu/drm/msm/Makefile | 1 +

[PATCH 14/17] drm/msm: Add a parameter query for the number of ringbuffers

In order to manage ringbuffer priority to its fullest userspace should know how many ringbuffers it has to work with. Add a parameter to return the number of active rings. Signed-off-by: Jordan Crouse --- drivers/gpu/drm/msm/adreno/adreno_gpu.c | 3 +++

[PATCH 10/17] drm/msm: Attach the GPU MMU when it is created

Currently the GPU MMU is attached in the adreno_gpu code but as more and more of the GPU initialization moves to the generic GPU path we have a need to map and use GPU memory earlier and earlier. There isn't any reason to defer attaching the MMU until later so attach it right after the address

Re: [PATCH 1/5] drm/atomic: Prepare drm_modeset_lock infrastructure for interruptible waiting

Op 27-07-17 om 17:19 schreef Daniel Vetter: > On Thu, Jul 27, 2017 at 02:58:36PM +0200, Maarten Lankhorst wrote: >> When we want to make drm_atomic_commit interruptible, there are a lot of >> places that call the lock function, which we don't have control over. >> >> Rather than trying to convert

[PATCH 13/17] drm/msm: Support multiple ringbuffers

Add the infrastructure to support the idea of multiple ringbuffers. Assign each ringbuffer an id and use that as an index for the various ring specific operations. The biggest delta is to support legacy fences. Each fence gets its own sequence number but the legacy functions expect to use a

[PATCH 04/17] drm/msm: Remove uneeded platform dev members

Commit eeb754746b14 ("drm/msm/gpu: use pm-runtime") adds a pointer for the GPU platform device to the msm_gpu struct so we can happily remove the same pointers from the individual GPU structs. Signed-off-by: Jordan Crouse --- drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 2 --

[PATCH 06/17] drm/msm: Remove __user from __u64 data types

__user should be used to identify user pointers and not __u64 variables containing pointers. Signed-off-by: Jordan Crouse --- include/uapi/drm/msm_drm.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/include/uapi/drm/msm_drm.h

[PATCH 16/17] drm/msm: Make the value of RB_CNTL (almost) generic

We use a global ringbuffer size and block size for all targets and at least for 5XX preemption we need to know the value the RB_CNTL in several locations so it makes sense to calculate it once and use it everywhere. The only monkey wrench is that we need to disable the RPTR shadow for A430

[PATCH 15/17] drm/msm: Shadow current pointer in the ring until command is complete

Add a shadow pointer to track the current command being written into the ring. Don't commit it as 'cur' until the command is submitted. Because 'cur' is used to construct the software copy of the wptr this ensures that somebody peeking in on the ring doesn't assume that a command is inflight while

[PATCH 08/17] drm/msm: Add per-instance submit queues

Currently the behavior of a command stream is provided by the user application during submission and the application is expected to internally maintain the settings for each 'context' or 'rendering queue' and specify the correct ones. This works okay for simple cases but as applications become

Re: [PATCH v6 4/7] drm/rockchip: vop: group vop registers

Hi Heiko Thanks for the test. On 2017年07月27日 18:10, Heiko Stübner wrote: Am Donnerstag, 27. Juli 2017, 11:51:06 CEST schrieb Heiko Stübner: Hi Mark, Am Mittwoch, 26. Juli 2017, 14:19:25 CEST schrieb Mark Yao: Grouping the vop registers facilitates make register definition clearer, and also

Re: [PATCH 06/41] drm/atmel-hlcdc: Use .dumb_map_offset and .dumb_destroy defaults

Le Sun, 23 Jul 2017 21:16:22 +0200, Noralf Trønnes a écrit : > This driver can use the drm_driver.dumb_destroy and > drm_driver.dumb_map_offset defaults, so no need to set them. > > Cc: Boris Brezillon > Signed-off-by: Noralf Trønnes

Re: [PATCH 0/5] drm/atomic: Interruptible locks for everyone!

On 27 July 2017 at 16:30, Daniel Vetter wrote: > On Thu, Jul 27, 2017 at 03:45:11PM +0100, Emil Velikov wrote: >> Hi Maarten >> >> On 27 July 2017 at 13:58, Maarten Lankhorst >> wrote: >> > drm_atomic_commit could previous have always failed

[PULL] drm-misc-fixes

Hi Dave, Only a handful of patches for -fixes from -misc. Everything is pretty easy to rationalize, nothing newsworthy. drm-misc-fixes-2017-07-27: Core Changes: - dp: A few fixes in drm_dp_downstream_debug() (Chris) - rockchip: sanitize the Kconfig dependencies (fallout from EXTCON) (Arnd) -

[PATCH] dma-buf/sw_sync: hold a fence reference when check if it signaled

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 a thus try to hold the lock to remove the fence from the

Re: [PATCH] dma-buf/sw_sync: hold a fence reference when check if it signaled

Quoting Gustavo Padovan (2017-07-27 20:03:53) > 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 a >

[PULL] drm-intel-fixes

Hi Dave, drm-intel-fixes-2017-07-27: i915 fixes for -rc3 Bit more than usual since we missed -rc2. 4x cc: stable, 2 gvt patches, but all fairly minor stuff. Last minute rebase was to add a few missing cc: stable, I did prep the pull this morning already and made sure CI approves. Cheers, Daniel

Re: [PATCHv1 00/14] omapdrm: DSI command mode panel support

* Sebastian Reichel [170724 10:34]: > Hi, > > This adds support for command mode DSI panels to > omapdrm. I tested the patches on Nokia N950 (omap3) > and Motorola Droid 4 (omap4). This is basically > PATCHv3 of my series adding N950 display support, > but I

Re: [PATCH v2 resend] drm/panel: Add driver for Seiko 43WVF1G panel

Thierry, 2017-07-20 13:12 GMT-03:00 Marco Franchi : > Add driver for Seiko Instruments Inc. 4.3" WVGA (800 x RGB x 480) > TFT with Touch-Panel. > > Datasheet available at: > http://www.glyn.de/data/glyn/media/doc/43wvf1g-0.pdf > > Seiko 43WVF1G panel has two power

Re: [PATCH] android: amdgpu: move asic id table to a separate file

2017-07-27 10:30 GMT+02:00 Chih-Wei Huang : >> 2017-07-26 17:27 GMT+02:00 Emil Velikov : >>> On 25 July 2017 at 08:28, Chih-Wei Huang wrote: Hi Mauro, Please note AMDGPU_ASIC_ID_TABLE should be a path in

Re: [PATCH] drm/amd/powerplay: rv: Use designated initializers

On Tue, Jul 25, 2017 at 5:47 PM, Kees Cook wrote: > As done for vega10 in commit 3ddd396f6b57 ("drm/amd/powerplay: Use > designated initializers") mark other tableFunction entries with designated > initializers. The randstruct plugin requires designated initializers for >

[git pull] drm fixes for v4.13-rc3

Hi Linus, This is the fixes for 4.13-rc3, as expected people woke up this week, i915 didn't do an -rc2 pull so got a bumper -rc3 pull, and Ben resurfaced on nouveau and fixed a bunch of major crashers seen on Fedora 26, and there are a few vmwgfx fixes as well. Otherwise exynos had some

Re: [PATCH] dma-buf/sw_sync: hold a fence reference when check if it signaled

2017-07-27 Chris Wilson : > Quoting Gustavo Padovan (2017-07-27 20:03:53) > > 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 > >

Re: [PATCH v6 4/7] drm/rockchip: vop: group vop registers

Hi Heiko On 2017年07月28日 09:02, Mark yao wrote: Hi Heiko Thanks for the test. On 2017年07月27日 18:10, Heiko Stübner wrote: Am Donnerstag, 27. Juli 2017, 11:51:06 CEST schrieb Heiko Stübner: Hi Mark, Am Mittwoch, 26. Juli 2017, 14:19:25 CEST schrieb Mark Yao: Grouping the vop registers

[Bug 101594] Blender doesn't detect OpenCL with Clover

https://bugs.freedesktop.org/show_bug.cgi?id=101594 Jan Vesely changed: What|Removed |Added Blocks||99553 Referenced

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

https://bugs.freedesktop.org/show_bug.cgi?id=99553 Jan Vesely changed: What|Removed |Added Depends on||101594 Referenced

Re: [PATCH] drm/bridge: tc358767: fix probe without attached output node

On 07/27/2017 06:26 PM, Andrey Gusakov wrote: Hi, On Mon, Jul 10, 2017 at 3:41 PM, Lucas Stach > wrote: The output node of the TC358767 is only used if another bridge is chained behind it. Panels attached to the TC358767 can be