[PATCH] [RFC] drm/i915/dp: add support for load detect Apple DP->VGA dongles

On Fri, Jun 06, 2014 at 12:57:46PM +0300, Jani Nikula wrote: > On Fri, 06 Jun 2014, Dave Airlie wrote: > > From: Dave Airlie > > > > The DP1.2 spec has some bits for forced load sensing on VGA dongles, > > however the apple dongle I have doesn't do DP 1.2 yet, so I dug into > > its vendor

[REPOST PATCH 1/8] fence: dma-buf cross-device synchronization (v17)

On Thu, Jun 19, 2014 at 8:19 PM, Greg KH wrote: >> >> > EXPORT_SYMBOL_GPL()? Same goes for all of the exports in here. >> >> > Traditionally all of the driver core exports have been with this >> >> > marking, any objection to making that change here as well? >> >> >> >> tbh, I prefer

[REPOST PATCH 1/8] fence: dma-buf cross-device synchronization (v17)

On Thu, Jun 19, 2014 at 7:00 PM, Greg KH wrote: >> >> + BUG_ON(f1->context != f2->context); >> > >> > Nice, you just crashed the kernel, making it impossible to debug or >> > recover :( >> >> agreed, that should probably be 'if (WARN_ON(...)) return NULL;' >> >> (but at least I wouldn't

[PATCH v2] drivers/i915: Fix unnoticed failure of init_ring_common()

On Thu, Jun 19, 2014 at 07:07:15PM +0200, Konrad Zapalowicz wrote: > This commit add check for return value of init_ring_common() in the > init_render_ring(). Now, when failure is detected the error code is > propagated to the caller instead of being ignored. > > Signed-off-by: Konrad Zapalowicz

[PATCH 0/3] Remove devm_request_and_ioremap()

re Size: 819 bytes Desc: Digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140619/d0af9782/attachment-0001.sig>

[PATCH 1/3] DRM: Armada: Use devm_ioremap_resource

From: Tushar Behera While at it, propagate the error code. Signed-off-by: Tushar Behera Signed-off-by: Wolfram Sang --- drivers/gpu/drm/armada/armada_crtc.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git

[PATCH 0/3] Remove devm_request_and_ioremap()

Pretty much a year ago, Tushar cleaned up a lot of deprecated uses of devm_request_and_ioremap, yet some remains are still left. Remove the last two users, and let the function rest in peace. I'd suggest that this series is picked up as a whole to have that case finally closed. Greg? Are you

[RFC] drm/exynos: abort commit when framebuffer is removed from plane

This situation arises when userspace remove the frambuffer object and call setmode ioctl. drm_mode_rmfb --> drm_plane_force_disable --> plane->crtc = NULL; and drm_mode_setcrtc --> exynos_plane_commit --> passes plane->crtc to exynos_drm_crtc_plane_commit which is NULL. This crashes the system.

[PATCH 0/3] Remove devm_request_and_ioremap()

On Fri, Jun 20, 2014 at 11:36:03AM +0900, Jingoo Han wrote: > On Friday, June 20, 2014 3:49 AM, Wolfram Sang wrote: > > > > Pretty much a year ago, Tushar cleaned up a lot of deprecated uses of > > devm_request_and_ioremap, yet some remains are still left. Remove the last > > two > > users, and

[REPOST PATCH 1/8] fence: dma-buf cross-device synchronization (v17)

On Thu, Jun 19, 2014 at 5:50 PM, Dave Airlie wrote: > On 20 June 2014 04:19, Greg KH wrote: >> On Thu, Jun 19, 2014 at 01:45:30PM -0400, Rob Clark wrote: >>> On Thu, Jun 19, 2014 at 1:00 PM, Greg KH >>> wrote: >>> > On Thu, Jun 19, 2014 at 10:00:18AM -0400, Rob Clark wrote: >>> >> On Wed, Jun

AGP GART clarifications, please!

DRI gurus, If I'm not mistaken, the current Linux graphics stack is as follows (excluding Wayland protocol and LLVM or GLAMOR-based approaches): X11/OpenGL app -> libX/Mesa -> DDX driver/Mesa DRI module -> kernel DRM -> hardware What's unclear to me is, in the case of an AGP graphics adapter,

[PATCH v2] drivers/i915: Fix unnoticed failure of init_ring_common()

This commit add check for return value of init_ring_common() in the init_render_ring(). Now, when failure is detected the error code is propagated to the caller instead of being ignored. Signed-off-by: Konrad Zapalowicz --- v2: - remove from commit message references to the Oops.

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

chives/dri-devel/attachments/20140619/e0525dea/attachment.html>

[REPOST PATCH 4/8] android: convert sync to fence api, v5

On Thu, Jun 19, 2014 at 08:35:29AM -0700, Colin Cross wrote: > On Thu, Jun 19, 2014 at 5:28 AM, Daniel Vetter wrote: > > On Thu, Jun 19, 2014 at 1:48 PM, Thierry Reding > > wrote: > >>> > With these changes, can we pull the android sync logic out of > >>> > drivers/staging/ now? > >>> > >>>

[PATCH libdrm 1/2] intel: Sync the command parser version parameter from kernel

On Thu, Jun 19, 2014 at 09:28:08AM -0700, Volkin, Bradley D wrote: > On Thu, Jun 19, 2014 at 11:31:53AM +0100, Damien Lespiau wrote: > > Cc: Bradley Volkin > > Signed-off-by: Damien Lespiau > > Thanks for taking care of this Damien. > > Reviewed-by: Brad Volkin Thanks for the review, pushed

[PATCH 3/3] drm/tegra: sor - Use bpc value from drm_panel

This change uses the bpc value coming from drm_panel to remove one more hardcoded value. Signed-off-by: St?phane Marchesin --- drivers/gpu/drm/tegra/sor.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c index

[PATCH 2/3] drm/panel: panel-simple - Add support for bpc

bpc is provided by the EDID normally, but if we're using drm_panel, we need to store it somewhere. So we add a drm_panel entry for it. Signed-off-by: St?phane Marchesin --- drivers/gpu/drm/panel/panel-simple.c | 9 + 1 file changed, 9 insertions(+) diff --git

[PATCH 1/3] drm/tegra: sor - Add register debugging support

This adds a debugfs entry to print the register state. This can be pretty useful when debugging eDP link issues. Signed-off-by: St?phane Marchesin --- drivers/gpu/drm/tegra/sor.c | 159 +++- 1 file changed, 158 insertions(+), 1 deletion(-) diff --git

[REPOST PATCH 4/8] android: convert sync to fence api, v5

op 19-06-14 17:22, Colin Cross schreef: > On Wed, Jun 18, 2014 at 11:37 PM, Daniel Vetter wrote: >> On Wed, Jun 18, 2014 at 06:15:56PM -0700, Greg KH wrote: >>> On Wed, Jun 18, 2014 at 12:37:11PM +0200, Maarten Lankhorst wrote: Just to show it's easy. Android syncpoints can be

[PATCH] drm/msm: Implement msm drm fb_mmap callback function

On Thu, Jun 19, 2014 at 5:19 PM, Stephen Boyd wrote: > On 06/18/14 13:55, Hai Li wrote: >> diff --git a/drivers/gpu/drm/msm/msm_fbdev.c >> b/drivers/gpu/drm/msm/msm_fbdev.c >> index 4f4e7b4..2522f51 100644 >> --- a/drivers/gpu/drm/msm/msm_fbdev.c >> +++ b/drivers/gpu/drm/msm/msm_fbdev.c >> @@

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

Originally the reason to probe ISA bridge instead of Dev31:Fun0 is to make graphics device passthrough work easy for VMM, that only need to expose ISA bridge to let driver know the real hardware underneath. This is a requirement from virtualization team. Especially in that virtualized

[Intel-gfx] [PATCH 10/9] drm: Add dev->vblank_disable_immediate flag

On Mon, May 26, 2014 at 05:26:47PM +0300, ville.syrjala at linux.intel.com wrote: > From: Ville Syrj?l? > > Add a flag to drm_device which will cause the vblank code to bypass the > disable timer and always disable the vblank interrupt immediately when > the last reference is dropped. > >

[REPOST PATCH 1/8] fence: dma-buf cross-device synchronization (v17)

On Thu, Jun 19, 2014 at 03:39:47PM -0700, H. Peter Anvin wrote: > On 06/19/2014 01:01 PM, Greg KH wrote: > > On Thu, Jun 19, 2014 at 09:15:36PM +0200, Daniel Vetter wrote: > >> On Thu, Jun 19, 2014 at 7:00 PM, Greg KH > >> wrote: > >> + BUG_ON(f1->context != f2->context); > > > >

[PATCH] drivers/i915: Fix unnoticed failure of init_ring_common()

On 06/19, Daniel Vetter wrote: > On Thu, Jun 19, 2014 at 4:35 PM, Daniel Vetter > wrote: > > The actual bug we seem to have is blowing up on the ggtt_unpin in > > context_fini. Which is doubly-impossible: Gen4 doesn't have hw > > contexts, so should have dctx->obj == NULL. And ring init failures

[PATCH] drivers/i915: Fix unnoticed failure of init_ring_common()

On Thu, Jun 19, 2014 at 4:35 PM, Daniel Vetter wrote: > The actual bug we seem to have is blowing up on the ggtt_unpin in > context_fini. Which is doubly-impossible: Gen4 doesn't have hw > contexts, so should have dctx->obj == NULL. And ring init failures > fail earlier so shouldn't even hit the

[PATCH] drivers/i915: Fix unnoticed failure of init_ring_common()

Hm, that's a bit unexpected. You are on a gen4 device, which means we'll return the right error in the same function after a few more register writes. But those are harmless. On gen5+ we do more (call the pipe_control setup code), which could potentially clobber the error code. So your patch

[REPOST PATCH 1/8] fence: dma-buf cross-device synchronization (v17)

On Thu, 2014-06-19 at 15:39 -0700, H. Peter Anvin wrote: > On 06/19/2014 01:01 PM, Greg KH wrote: > > On Thu, Jun 19, 2014 at 09:15:36PM +0200, Daniel Vetter wrote: > >> On Thu, Jun 19, 2014 at 7:00 PM, Greg KH > >> wrote: > >> + BUG_ON(f1->context != f2->context); > > > > Nice,

[PATCH] drm/fb-helper: Remove unnecessary list empty check in drm_fb_helper_debug_enter()

The following list empty check is unnecessary because we would still do nothing real and return 'val' if my_list is empty. if (list_empty(_list)) return val; list_for_each_entry(pos, _list, member) { ... } return val; This patch removes the unnecessary check in

[PATCH] drm/tegra: sor - Add register debugging support

This adds a debugfs entry to print the register state. This can be fairly useful when debugging eDP link issues. Signed-off-by: St?phane Marchesin --- drivers/gpu/drm/tegra/sor.c | 163 +++- 1 file changed, 162 insertions(+), 1 deletion(-) diff --git

[REPOST PATCH 1/8] fence: dma-buf cross-device synchronization (v17)

On 06/19/2014 01:01 PM, Greg KH wrote: > On Thu, Jun 19, 2014 at 09:15:36PM +0200, Daniel Vetter wrote: >> On Thu, Jun 19, 2014 at 7:00 PM, Greg KH >> wrote: >> + BUG_ON(f1->context != f2->context); > > Nice, you just crashed the kernel, making it impossible to debug or >

[PATCH] drm/fb-helper: Return correct type to match drm_fb_helper_debug_enter() prototype

On 06/19/2014 03:01 PM, Daniel Vetter wrote: > On Thu, Jun 19, 2014 at 10:50:31AM +0800, Liu Ying wrote: >> The return type of drm_fb_helper_debug_enter() is int, so we should return >> '0' >> instead of 'false'. >> >> Signed-off-by: Liu Ying >> --- >> drivers/gpu/drm/drm_fb_helper.c |2 +-

[PATCH] drm/fb-helper: Redundant info->fix.type_aux setting in drm_fb_helper_fill_fix()

The variable info->fix.type_aux is set to zero twice in the function drm_fb_helper_fill_fix(). This patch removes one redundant. Signed-off-by: Liu Ying --- drivers/gpu/drm/drm_fb_helper.c |1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/drm_fb_helper.c

[PATCH v2 7/7] ARM: at91/dt: enable the LCD panel on sama5d3xek boards

Hi Boris, On 06/10/2014 12:04 AM, Boris BREZILLON wrote: > diff --git a/arch/arm/boot/dts/sama5d33ek.dts > b/arch/arm/boot/dts/sama5d33ek.dts > index cbd6a3f..f2ab41d 100644 > --- a/arch/arm/boot/dts/sama5d33ek.dts > +++ b/arch/arm/boot/dts/sama5d33ek.dts > @@ -36,9 +36,33 @@ >

[PATCH v2 4/7] ARM: at91/dt: split sama5d3 lcd pin definitions to match RGB mode configs

Hi Boris, On 06/10/2014 12:04 AM, Boris BREZILLON wrote: > The HLCDC (High LCD Controller) IP supports 4 different output mode > (RGB444, RGB565, RGB666 and RGB888) and the pin muxing depends on the > chosen RGB mode. > > Split the pin definition to be able to set the pin config according to the

[REPOST PATCH 1/8] fence: dma-buf cross-device synchronization (v17)

On Thu, Jun 19, 2014 at 2:19 PM, Greg KH wrote: > On Thu, Jun 19, 2014 at 01:45:30PM -0400, Rob Clark wrote: >> On Thu, Jun 19, 2014 at 1:00 PM, Greg KH >> wrote: >> > On Thu, Jun 19, 2014 at 10:00:18AM -0400, Rob Clark wrote: >> >> On Wed, Jun 18, 2014 at 9:13 PM, Greg KH >> >> wrote: >> >>

[PATCH] drivers/i915: Fix unnoticed failure of init_ring_common()

On 06/19, Daniel Vetter wrote: > On Thu, Jun 19, 2014 at 12:38 AM, Konrad Zapalowicz > wrote: > > This commit add check for return value of init_ring_common() in the > > init_render_ring(). Now, when failure is detected the error code is > > propagated to the caller layer instead of being

[REPOST PATCH 4/8] android: convert sync to fence api, v5

On Thu, Jun 19, 2014 at 1:48 PM, Thierry Reding wrote: >> > With these changes, can we pull the android sync logic out of >> > drivers/staging/ now? >> >> Afaik the google guys never really looked at this and acked it. So I'm not >> sure whether they'll follow along. The other issue I have as the

[PATCH] drm/msm: Implement msm drm fb_mmap callback function

On 06/18/14 13:55, Hai Li wrote: > diff --git a/drivers/gpu/drm/msm/msm_fbdev.c b/drivers/gpu/drm/msm/msm_fbdev.c > index 4f4e7b4..2522f51 100644 > --- a/drivers/gpu/drm/msm/msm_fbdev.c > +++ b/drivers/gpu/drm/msm/msm_fbdev.c > @@ -19,6 +19,11 @@ > > #include "drm_crtc.h" > #include

[Bug 68571] GPU lockup on AMD Radeon HD6850 with DPM=1

https://bugzilla.kernel.org/show_bug.cgi?id=68571 --- Comment #41 from perry3d at gmail.com --- Hello kilobug, Alex marked my bug (https://bugzilla.kernel.org/show_bug.cgi?id=78321) as a duplicate. And my solution is to disable the hdmi audio output. You can do this by appending radeon.audio=0

[REPOST PATCH 4/8] android: convert sync to fence api, v5

deadlocks in some use-cases (this was mentioned for Android compositing, but I suspect that the same may happen for Wayland or X compositors). Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140619/651c1fff/attachment.sig>

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

https://bugzilla.kernel.org/show_bug.cgi?id=78221 --- Comment #4 from Alex Deucher --- Can you bisect and see what fixed it in 3.15 or what broke it again in 3.16? -- You are receiving this mail because: You are watching the assignee of the bug.

[REPOST PATCH 1/8] fence: dma-buf cross-device synchronization (v17)

On Thu, Jun 19, 2014 at 1:00 PM, Greg KH wrote: > On Thu, Jun 19, 2014 at 10:00:18AM -0400, Rob Clark wrote: >> On Wed, Jun 18, 2014 at 9:13 PM, Greg KH >> wrote: >> > On Wed, Jun 18, 2014 at 12:36:54PM +0200, Maarten Lankhorst wrote: >> >> +#define CREATE_TRACE_POINTS >> >> +#include >> >> +

[PATCH v2 4/7] ARM: at91/dt: split sama5d3 lcd pin definitions to match RGB mode configs

On 19/06/2014 09:07, Bo Shen wrote: > Hi Boris, > > On 06/10/2014 12:04 AM, Boris BREZILLON wrote: >> The HLCDC (High LCD Controller) IP supports 4 different output mode >> (RGB444, RGB565, RGB666 and RGB888) and the pin muxing depends on the >> chosen RGB mode. >> >> Split the pin definition to

[Bug 80235] Artifacts in kernel 3.16-rc1 and HD 7750

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

[Bug 80235] Artifacts in kernel 3.16-rc1 and HD 7750

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

[Bug 80235] Artifacts in kernel 3.16-rc1 and HD 7750

You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140619/540d9c1b/attachment.html>

[Bug 80235] Artifacts in kernel 3.16-rc1 and HD 7750

bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140619/cd567654/attachment.html>

[Bug 80235] Artifacts in kernel 3.16-rc1 and HD 7750

bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140619/44876a81/attachment.html>

[Bug 80235] Artifacts in kernel 3.16-rc1 and HD 7750

bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140619/d88b87ab/attachment.html>

[Bug 80235] New: Artifacts in kernel 3.16-rc1 and HD 7750

t;http://lists.freedesktop.org/archives/dri-devel/attachments/20140619/dbe3fc3b/attachment.html>

[Bug 78321] Xorg Freeze with radeon.dpm=1

https://bugzilla.kernel.org/show_bug.cgi?id=78321 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #3

[PATCH/RESEND 0/9] drm: tilcdc driver fixes

Hi Darren, On Thu, Jun 19, 2014 at 08:41:43AM -0500, Darren Etheridge wrote: > Guido, > > Thanks and sorry I missed this the first time around. I'll give it a try on > a few of my AM335x based boards when I have access to them again on Monday. Thanks! And no worries :) > > Darren > -- Guido

[Bug 80233] DirectX wine crush

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

[PATCH] drm/exynos: defer hdmi probe when fail to get regulators

On 2014? 06? 18? 22:42, Rahul Sharma wrote: > HDMI probe proceeds with dummy regulators when the regulators > are not provided in DT node or regulator provider has not get > probed or failed to register the regulators. > > This patch modify hdmi driver to defer the probe in case the > regulators

[REPOST PATCH 1/8] fence: dma-buf cross-device synchronization (v17)

On Thu, Jun 19, 2014 at 09:15:36PM +0200, Daniel Vetter wrote: > On Thu, Jun 19, 2014 at 7:00 PM, Greg KH > wrote: > >> >> + BUG_ON(f1->context != f2->context); > >> > > >> > Nice, you just crashed the kernel, making it impossible to debug or > >> > recover :( > >> > >> agreed, that should

[REPOST PATCH 1/8] fence: dma-buf cross-device synchronization (v17)

Eric Boxer liked your message with Boxer. On June 19, 2014 at 12:45:30 PM CDT, Rob Clark wrote: -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140619/bac88f05/attachment.html>

[PATCH] drm/radeon: fix race condition in radeon_crtc_page_flip

This patch only applies to 3.15, right? On 19.06.2014 02:11, Christian K?nig wrote: > From: Christian K?nig > > radeon_crtc_handle_flip can be called concurrently and if > we set the unpin_work to early try to flip an unpinned BO or > worse. Spelling: 'too early' Maybe something like:

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

Hi Marek, > There is a workaround in 3.15 which disables sDMA and uses CP DMA for > copying buffers. It seems to help Christian's machine, but not mine. With stressing the box with piglit I was able to bring my machine down with the CP DMA as well, only cherry-picking the "stop poisoning the

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

Hi Michel, 3.15 doesn't contain Christian's fix yet, so it should be always broken for everybody. The fix is currently only in 3.16. Alternatively, you can cherry-pick the fix to 3.15, but it doesn't apply cleanly. There is a workaround in 3.15 which disables sDMA and uses CP DMA for copying

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

have a couple of unsolved problems with the VM support or in the driver in general where we should try to understand the underlying reason for it instead of applying more workarounds. Going to try harder crashing my 3.15 system, Christian. -- next part ------ A non-text attachment was scrubbed... Name: 0001-drm-radeon-pin-down-page-tables.patch Type: text/x-diff Size: 1008 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140619/b0b7a8df/attachment.patch>

[REPOST PATCH 1/8] fence: dma-buf cross-device synchronization (v17)

On Thu, 2014-06-19 at 11:19 -0700, Greg KH wrote: > On Thu, Jun 19, 2014 at 01:45:30PM -0400, Rob Clark wrote: > > On Thu, Jun 19, 2014 at 1:00 PM, Greg KH > > wrote: > > > On Thu, Jun 19, 2014 at 10:00:18AM -0400, Rob Clark wrote: > > >> On Wed, Jun 18, 2014 at 9:13 PM, Greg KH > > >> wrote:

[PATCH libdrm 2/2] intel: Sync typo fix from the kernel sources.

Signed-off-by: Damien Lespiau --- include/drm/i915_drm.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h index 980dbf8..8eb0cb3 100644 --- a/include/drm/i915_drm.h +++ b/include/drm/i915_drm.h @@ -722,7 +722,7 @@ struct

[PATCH libdrm 1/2] intel: Sync the command parser version parameter from kernel

Cc: Bradley Volkin Signed-off-by: Damien Lespiau --- include/drm/i915_drm.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h index 2f4eb8c..980dbf8 100644 --- a/include/drm/i915_drm.h +++ b/include/drm/i915_drm.h @@ -337,6 +337,7 @@ typedef

[PATCH] drm/radeon: fix race condition in radeon_crtc_page_flip

Am 19.06.2014 05:49, schrieb Michel D?nzer: > This patch only applies to 3.15, right? Yes correct. For 3.16 we have the reworked flip which I think is still a good idea to keep for now. I've addresses your comments and send out a v2 to the list CCing you, please review. Thanks, Christian. >

[PATCH] drm/radeon: fix race condition in radeon_crtc_page_flip v2

From: Christian K?nig radeon_crtc_handle_flip can be called concurrently, and if we set the unpin_work too early, it may try to flip an unpinned BO or worse. v2: fix compiler warning, update commit message, set crtc->primary->fb only when everything went well

[REPOST PATCH 1/8] fence: dma-buf cross-device synchronization (v17)

On Thu, Jun 19, 2014 at 01:45:30PM -0400, Rob Clark wrote: > On Thu, Jun 19, 2014 at 1:00 PM, Greg KH > wrote: > > On Thu, Jun 19, 2014 at 10:00:18AM -0400, Rob Clark wrote: > >> On Wed, Jun 18, 2014 at 9:13 PM, Greg KH > >> wrote: > >> > On Wed, Jun 18, 2014 at 12:36:54PM +0200, Maarten

[Bug 75061] System boot failure very often

https://bugzilla.kernel.org/show_bug.cgi?id=75061 --- Comment #1 from Yuking --- Created attachment 140391 --> https://bugzilla.kernel.org/attachment.cgi?id=140391=edit X crashed caused by kernel crash. -- You are receiving this mail because: You are watching the assignee of the bug.

[REPOST PATCH 1/8] fence: dma-buf cross-device synchronization (v17)

On 19 June 2014 10:24, Greg KH wrote: > On Thu, Jun 19, 2014 at 09:57:35AM +0530, Sumit Semwal wrote: >> Hi Greg, >> >> >> >> >> Who is going to sign up to maintain this code? (hint, it's not me...) >> > >> > that would be Sumit (dma-buf tree).. >> > >> > probably we should move

[PATCH] drm/fb-helper: Return correct type to match drm_fb_helper_debug_enter() prototype

The return type of drm_fb_helper_debug_enter() is int, so we should return '0' instead of 'false'. Signed-off-by: Liu Ying --- drivers/gpu/drm/drm_fb_helper.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c

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

On 15.06.2014 21:48, Christian K?nig wrote: > Am 13.06.2014 23:31, schrieb Alex Deucher: >> On Fri, Jun 13, 2014 at 11:45 AM, Christian K?nig >> wrote: >>> Hi Marek, >>> >>> ah, yes! Piglit in combination with that patch can indeed crash the box. >>> >>> Going to investigate now that I can

[PATCH v3 RESEND] drm/i2c: tda998x: Fix lack of required reg in DT documentation

The I2C address (reg) is required for the TDA998x driver to be loaded and initialized. Signed-off-by: Jean-Francois Moine --- - v3 - change subject to drm/i2c - v2 - don't force the I2C address to be 0x70 This patch applies to linux-next. ---

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

On 06/18/14 23:16, Stephen Rothwell wrote: > Hi all, > > The powerpc allyesconfig is again broken more than usual. > > Changes since 20140618: > on i386: CONFIG_ACPI is not enabled. CC drivers/gpu/drm/i915/i915_drv.o ../drivers/gpu/drm/i915/i915_drv.c: In function 'i915_drm_freeze':

[PATCH] drm/fb-helper: Remove unnecessary list empty check in drm_fb_helper_debug_enter()

On Thu, Jun 19, 2014 at 04:01:44PM +0800, Liu Ying wrote: > The following list empty check is unnecessary because we would still do > nothing > real and return 'val' if my_list is empty. > > if (list_empty(_list)) > return val; > > list_for_each_entry(pos, _list, member) { > ... > }

[PATCH] drm/exynos: defer hdmi probe when fail to get regulators

Thanks Inki, On 19 June 2014 09:34, Inki Dae wrote: > On 2014? 06? 18? 22:42, Rahul Sharma wrote: >> HDMI probe proceeds with dummy regulators when the regulators >> are not provided in DT node or regulator provider has not get >> probed or failed to register the regulators. >> >> This patch

[REPOST PATCH 1/8] fence: dma-buf cross-device synchronization (v17)

On Thu, Jun 19, 2014 at 10:00:18AM -0400, Rob Clark wrote: > On Wed, Jun 18, 2014 at 9:13 PM, Greg KH > wrote: > > On Wed, Jun 18, 2014 at 12:36:54PM +0200, Maarten Lankhorst wrote: > >> +#define CREATE_TRACE_POINTS > >> +#include > >> + > >> +EXPORT_TRACEPOINT_SYMBOL(fence_annotate_wait_on); >

[REPOST PATCH 1/8] fence: dma-buf cross-device synchronization (v17)

On Wed, Jun 18, 2014 at 9:13 PM, Greg KH wrote: > On Wed, Jun 18, 2014 at 12:36:54PM +0200, Maarten Lankhorst wrote: >> +#define CREATE_TRACE_POINTS >> +#include >> + >> +EXPORT_TRACEPOINT_SYMBOL(fence_annotate_wait_on); >> +EXPORT_TRACEPOINT_SYMBOL(fence_emit); > > Are you really willing to

[REPOST PATCH 1/8] fence: dma-buf cross-device synchronization (v17)

Hi Greg, On 19 June 2014 06:55, Rob Clark wrote: > On Wed, Jun 18, 2014 at 9:16 PM, Greg KH > wrote: >> On Wed, Jun 18, 2014 at 12:36:54PM +0200, Maarten Lankhorst wrote: >>> A fence can be attached to a buffer which is being filled or consumed >>> by hw, to allow userspace to pass the buffer

[PATCH v2 7/7] ARM: at91/dt: enable the LCD panel on sama5d3xek boards

On 19/06/2014 09:12, Bo Shen wrote: > Hi Boris, > > On 06/10/2014 12:04 AM, Boris BREZILLON wrote: >> diff --git a/arch/arm/boot/dts/sama5d33ek.dts >> b/arch/arm/boot/dts/sama5d33ek.dts >> index cbd6a3f..f2ab41d 100644 >> --- a/arch/arm/boot/dts/sama5d33ek.dts >> +++

[PATCH v2 4/7] ARM: at91/dt: split sama5d3 lcd pin definitions to match RGB mode configs

Hello Bo, On 19/06/2014 09:07, Bo Shen wrote: > Hi Boris, > > On 06/10/2014 12:04 AM, Boris BREZILLON wrote: >> The HLCDC (High LCD Controller) IP supports 4 different output mode >> (RGB444, RGB565, RGB666 and RGB888) and the pin muxing depends on the >> chosen RGB mode. >> >> Split the pin

[PATCH libdrm 1/2] intel: Sync the command parser version parameter from kernel

On Thu, Jun 19, 2014 at 11:31:53AM +0100, Damien Lespiau wrote: > Cc: Bradley Volkin > Signed-off-by: Damien Lespiau Thanks for taking care of this Damien. Reviewed-by: Brad Volkin > --- > include/drm/i915_drm.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git

[PATCH] drm/fb-helper: Redundant info->fix.type_aux setting in drm_fb_helper_fill_fix()

On Thu, Jun 19, 2014 at 03:14:37PM +0800, Liu Ying wrote: > The variable info->fix.type_aux is set to zero twice in the function > drm_fb_helper_fill_fix(). This patch removes one redundant. > > Signed-off-by: Liu Ying Merged into my topic/core-stuff branch, will show up in 3.17. -Daniel >

[PATCH] drm/fb-helper: Return correct type to match drm_fb_helper_debug_enter() prototype

On Thu, Jun 19, 2014 at 10:50:31AM +0800, Liu Ying wrote: > The return type of drm_fb_helper_debug_enter() is int, so we should return '0' > instead of 'false'. > > Signed-off-by: Liu Ying > --- > drivers/gpu/drm/drm_fb_helper.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >

[PATCH 1/3] drm: add register and unregister functions for connectors

On Tue, Jun 10, 2014 at 06:21:35PM +0200, David Herrmann wrote: > Hi > > On Thu, May 29, 2014 at 5:57 PM, Thomas Wood wrote: > > Introduce generic functions to register and unregister connectors. This > > provides a common place to add and remove associated user space > > interfaces. > > > >

[PATCH/RESEND 0/9] drm: tilcdc driver fixes

Guido, Thanks and sorry I missed this the first time around. I'll give it a try on a few of my AM335x based boards when I have access to them again on Monday. Darren On 06/17/2014 09:17 AM, Guido Mart?nez wrote: > The tilcdc driver could be compiled as a module, but was severely broken > and

[REPOST PATCH 4/8] android: convert sync to fence api, v5

On Wed, Jun 18, 2014 at 06:15:56PM -0700, Greg KH wrote: > On Wed, Jun 18, 2014 at 12:37:11PM +0200, Maarten Lankhorst wrote: > > Just to show it's easy. > > > > Android syncpoints can be mapped to a timeline. This removes the need > > to maintain a separate api for synchronization. I've left the

[REPOST PATCH 4/8] android: convert sync to fence api, v5

On Thu, Jun 19, 2014 at 5:28 AM, Daniel Vetter wrote: > On Thu, Jun 19, 2014 at 1:48 PM, Thierry Reding > wrote: >>> > With these changes, can we pull the android sync logic out of >>> > drivers/staging/ now? >>> >>> Afaik the google guys never really looked at this and acked it. So I'm not >>>

[REPOST PATCH 4/8] android: convert sync to fence api, v5

On Wed, Jun 18, 2014 at 11:37 PM, Daniel Vetter wrote: > On Wed, Jun 18, 2014 at 06:15:56PM -0700, Greg KH wrote: >> On Wed, Jun 18, 2014 at 12:37:11PM +0200, Maarten Lankhorst wrote: >> > Just to show it's easy. >> > >> > Android syncpoints can be mapped to a timeline. This removes the need >> >

[PATCH] drivers/i915: Fix unnoticed failure of init_ring_common()

On Thu, Jun 19, 2014 at 12:38 AM, Konrad Zapalowicz wrote: > This commit add check for return value of init_ring_common() in the > init_render_ring(). Now, when failure is detected the error code is > propagated to the caller layer instead of being ignored. > > I believe that this fix will have a

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

https://bugzilla.kernel.org/show_bug.cgi?id=78221 --- Comment #3 from t3st3r at mail.ru --- Not looks like this. Re-checked again, using very same version of drivers in process. I'm unable to trigged bug with 3.15 mainline kernel, no matter what. But it happens easily with older kernels like 3.14

[Bug 79980] Random radeonsi crashes

An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140619/58d96949/attachment.html>

[Bug 78321] Xorg Freeze with radeon.dpm=1

https://bugzilla.kernel.org/show_bug.cgi?id=78321 --- Comment #2 from perry3d at gmail.com --- Instead of blacklisting the kernel modules, adding radeon.audio=0 to the kernel parameters also helps. For me this is a workaround as i don't need the hdmi audio output. -- You are receiving this

[Bug 78321] Xorg Freeze with radeon.dpm=1

https://bugzilla.kernel.org/show_bug.cgi?id=78321 --- Comment #1 from perry3d at gmail.com --- Kernel build from git doesn't help. The freeze seems to be related to the hdmi audio output. If i blacklist the snd_hda_intel and the snd_hda_codec_hdmi modules the system is running fine (at least for

[Bug 78321] New: Xorg Freeze with radeon.dpm=1

https://bugzilla.kernel.org/show_bug.cgi?id=78321 Bug ID: 78321 Summary: Xorg Freeze with radeon.dpm=1 Product: Drivers Version: 2.5 Kernel Version: 3.15.1-1-ARCH Hardware: x86-64 OS: Linux Tree: Mainline

[git pull] drm fixes

Hi Linus, this looks bigger than it is, as one of the nouveau firmware fixes "drm/gf100-/gr: report class data to host on fwmthd failure" regenerates a bunch of the firmware files after changing the assembly by a few lines, without that, its more of a " 36 files changed, 370 insertions(+), 129

[PATCH] drm/tegra: add MODULE_DEVICE_TABLEs

ors, otherwise this looks good to me. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140619/f8e967b0/attachment-0001.sig>

[RFC PATCH 1/4] memory: tegra124-emc: Add EMC driver

me time? I guess depending on the timing you could get FIFO underflows if the registers aren't updated promptly enough. Once the programming takes effect things should be able to catch up again, but it's possible that there could be glitches. > Even if there's some co-ordination required, > maybe it can be handled rather like cpufreq notifications; use clock > pre-rate change notifications to set MC up in a way that'll work at both > old/new EMC clocks, and then clock post-rate notifications to the final > MC configuration? Yes, I think something like that should work. As I understand it, the latency allowance is dependent on the EMC frequency, so in case where the EMC frequency is increased, adjusting in a post-rate notifier should be fine. When the EMC frequency is decreased, then programming the latency allowance registers in a pre-rate notifier should allow glitch- free transition. Note that this is all purely theoretical knowledge, so I have no idea if it'll actually work like that in practice. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140619/24068e19/attachment.sig>

[RFC PATCH 1/4] memory: tegra124-emc: Add EMC driver

isn't about the individual clocks at > > all but rather about a mechanism to express constraints for a set of > > clocks? > > This doesn't have anything to do with virtual clocks. As you mention, > it's just about constraints. > > One user of clock "cpu" wants min rate 216MHz. Another wants max rate > 1GHz. cpufreq will request some rate between the 2, or be capped to > those limits. These set of imposed constraints would need to be stored > per client of the clock, not per HW clock, since many clients could set > different max rates (e.g. thermal throttle 1.5GHz due to temperature, > CPU policy 1GHz due to the user selecting low CPU power, etc.) > > Similarly for audio, of there are N clients of 1 clock/PLL, and they > each want the PLL to run at a different rate, something needs to detect > that and deny it. I'm wondering how this should work with the current API. Could the clock core be modified to return a per-client struct clk * that references the hardware clock internally? Or do we need to add a new API? Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140619/c06e9ba5/attachment.sig>

[PATCH] drivers/i915: Fix unnoticed failure of init_ring_common()

This commit add check for return value of init_ring_common() in the init_render_ring(). Now, when failure is detected the error code is propagated to the caller layer instead of being ignored. I believe that this fix will have a positive impact on the oops that I hit recently and which starts

[RFC PATCH 1/4] memory: tegra124-emc: Add EMC driver

On Wed, Jun 18, 2014 at 11:46:49AM -0600, Stephen Warren wrote: > On 06/18/2014 11:23 AM, Tomeu Vizoso wrote: > > On 06/17/2014 06:15 PM, Stephen Warren wrote: > >> On 06/17/2014 06:16 AM, Tomeu Vizoso wrote: > >>> On 06/16/2014 10:02 PM, Stephen Warren wrote: > On 06/16/2014 07:35 AM, Tomeu

[RFC PATCH 1/4] memory: tegra124-emc: Add EMC driver

rather than the EMC. So I think we have two options: a) have a unified driver for MC and EMC or b) provide two parts of the API in two drivers. Or perhaps c), create a generic framework that both MC and EMC can register with (bandwidth for EMC, latency for MC). Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140619/4ac6b0a7/attachment.sig>

  1   2   >