[PATCH] drm/exynos/fimd: only finish pageflip if START == START_S
On 2014ë
11ì 26ì¼ 03:12, Gustavo Padovan wrote:
> From: Daniel Kurtz
>
> A framebuffer gets committed to FIMD's default window like this:
> exynos_drm_crtc_update()
> exynos_plane_commit()
>fimd_win_commit()
>
> fimd_win_commit() programs BUF_START[0]. At each vblank, FIMD hardware
> copies the value from BUF_START to BUF_START_S (BUF_START's shadow
> register), starts scanning out from BUF_START_S, and asserts its irq.
>
> This irq is handled by fimd_irq_handler(), which calls
> exynos_drm_crtc_finish_pageflip() to free the old buffer that FIMD just
> finished scanning out, and potentially commit the next pending flip.
>
> There is a race, however, if fimd_win_commit() programs BUF_START(0)
> between the actual vblank irq, and its corresponding fimd_irq_handler().
>
> => FIMD vblank: BUF_START_S[0] := BUF_START[0], and irq asserted
> | => fimd_win_commit(0) writes new BUF_START[0]
> |exynos_drm_crtc_try_do_flip() marks exynos_fb as prepared
> => fimd_irq_handler()
> exynos_drm_crtc_finish_pageflip() sees prepared exynos_fb,
> and unmaps "old" fb
> ==> but, since BUF_START_S[0] still points to that "old" fb...
> ==> FIMD iommu fault
>
> This patch ensures that fimd_irq_handler() only calls
> exynos_drm_crtc_finish_pageflip() if any previously scheduled flip
> has really completed.
>
> This works because exynos_drm_crtc's flip fifo ensures that
> fimd_win_commit() is never called more than once per
> exynos_drm_crtc_finish_pageflip().
>
> Signed-off-by: Daniel Kurtz
> Reviewed-by: Sean Paul
> Signed-off-by: Gustavo Padovan
> ---
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 26 ++
> include/video/samsung_fimd.h | 1 +
> 2 files changed, 27 insertions(+)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index e5810d1..afb0586 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -55,6 +55,7 @@
> #define VIDOSD_D(win)(VIDOSD_BASE + 0x0C + (win) * 16)
>
> #define VIDWx_BUF_START(win, buf)(VIDW_BUF_START(buf) + (win) * 8)
> +#define VIDWx_BUF_START_S(win, buf) (VIDW_BUF_START_S(buf) + (win) * 8)
> #define VIDWx_BUF_END(win, buf) (VIDW_BUF_END(buf) + (win) * 8)
> #define VIDWx_BUF_SIZE(win, buf) (VIDW_BUF_SIZE(buf) + (win) * 4)
>
> @@ -1039,6 +1040,7 @@ static irqreturn_t fimd_irq_handler(int irq, void
> *dev_id)
> {
> struct fimd_context *ctx = (struct fimd_context *)dev_id;
> u32 val, clear_bit;
> + u32 start, start_s;
>
> val = readl(ctx->regs + VIDINTCON1);
>
> @@ -1066,6 +1068,30 @@ static irqreturn_t fimd_irq_handler(int irq, void
> *dev_id)
> }
> }
>
> + /*
> + * Ensure finish_pageflip is called iff a pending flip has completed.
> + * This works around a race between a page_flip request and the latency
> + * between vblank interrupt and this irq_handler:
> + * => FIMD vblank: BUF_START_S[0] := BUF_START[0], and asserts irq
> + * | => fimd_win_commit(0) writes new BUF_START[0]
> + * |exynos_drm_crtc_try_do_flip() marks exynos_fb as prepared
> + * => fimd_irq_handler()
> + * exynos_drm_crtc_finish_pageflip() sees prepared exynos_fb,
> + * and unmaps "old" fb
> + * ==> but, since BUF_START_S[0] still points to that "old" fb...
> + * ==> FIMD iommu fault
> + */
> + start = readl(ctx->regs + VIDWx_BUF_START(0, 0));
> + start_s = readl(ctx->regs + VIDWx_BUF_START_S(0, 0));
> + if (start == start_s)
> + exynos_drm_crtc_finish_pageflip(ctx->drm_dev, ctx->pipe);
> +
> + /* set wait vsync event to zero and wake up queue. */
> + if (atomic_read(&ctx->wait_vsync_event)) {
> + atomic_set(&ctx->wait_vsync_event, 0);
> + wake_up(&ctx->wait_vsync_queue);
> + }
Your patch makes codes duplicated. Above codes you added are called
already in case of using RGB interface. So move all your codes into RGB
interface routine if these codes are only valid in case of RGB interface.
Thanks,
Inki Dae
> +
> out:
> return IRQ_HANDLED;
> }
> diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
> index a20e4a3..f81d081 100644
> --- a/include/video/samsung_fimd.h
> +++ b/include/video/samsung_fimd.h
> @@ -291,6 +291,7 @@
>
> /* Video buffer addresses */
> #define VIDW_BUF_START(_buff)(0xA0 + ((_buff) * 8))
> +#define VIDW_BUF_START_S(_buff) (0x40A0 + ((_buff) * 8))
> #define VIDW_BUF_START1(_buff) (0xA4 + ((_buff) * 8))
> #define VIDW_BUF_END(_buff) (0xD0 + ((_buff) * 8))
> #define VIDW_BUF_END1(_buff) (0xD4 + ((_buff) * 8))
>
[Bug 73739] RV630 massive artifacts on "Wargame European Escalation"
https://bugs.freedesktop.org/show_bug.cgi?id=73739 --- Comment #8 from Dawid Zamirski --- This seems to be the game bug that affect other GPU's drivers as well: http://steamcommunity.com/app/58610/discussions/0/624075566952474599/ https://www.youtube.com/watch?v=HhGs-uKrfnM -- 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/20141209/61b733d9/attachment.html>
drm/exynos: some small forgotten patch
Hi, On 2014ë 11ì 30ì¼ 09:35, tjakobi at math.uni-bielefeld.de wrote: > Hello, > > while looking through my local kernel tree, I noticed that this patch > for the mixer component of drm/exynos, posted some time ago, was That might be a patch I missed. Can you tell me the Subject? Thanks, Inki Dae > never applied. Since this is an obvious (and small) fix, could this > still go into 3.19? > > With best wishes, > Tobias > > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
[PATCH] drm: fb helper should avoid sleeping in panic context
oh, whoops.. gmail hiding quoted text..
yeah, that looks sane,
Reviewed-by: Rob Clark
On Tue, Dec 9, 2014 at 7:55 PM, rui wang wrote:
> Hi Rob,
> Yes it's exactly what I'm doing. Please scroll down and review my patch.
>
> Thanks
> Rui
>
> On 12/10/14, Rob Clark wrote:
>> perhaps fb helpers could use __drm_modeset_lock_all() w/ trylock=true
>> in panic context?
>>
>> BR,
>> -R
>>
>> On Tue, Dec 9, 2014 at 7:09 PM, rui wang wrote:
>>> Hi All,
>>>
>>> Any comment ? Or any better idea how this should be fixed?
>>>
>>> Regards,
>>> Rui
>>>
>>> -- Forwarded message --
>>> From: ruiv.wang at gmail.com
>>> Date: Thu, 4 Dec 2014 22:11:35 +0800
>>> Subject: [PATCH] drm: fb helper should avoid sleeping in panic context
>>> To: airlied at redhat.com, daniel.vetter at ffwll.ch, tony.luck at
>>> intel.com,
>>> bp at alien8.de, aris at redhat.com, rui.y.wang at intel.com
>>> Cc: linux-kernel at vger.kernel.org
>>>
>>> From: Rui Wang
>>>
>>> There are still some places in the fb helper that need to avoid
>>> sleeping in panic context. Here's an example:
>>>
>>> [ 65.615496] bad: scheduling from the idle thread!
>>> [ 65.620747] CPU: 92 PID: 0 Comm: swapper/92 Tainted: G ME
>>> 3.18.0-rc4-7-default+ #20
>>>
>>> [ 65.630364] Hardware name: Intel Corporation BRICKLAND/BRICKLAND,
>>> BIOS BRHSXSD1.86B.0056.R01.1409242327 09/24/2014
>>> [ 65.641923] 88087f693d80 88087f689878 81566db9
>>>
>>> [ 65.650226] 88087f693d80 88087f689898 810871ff
>>> 88046eb3e0d0
>>> [ 65.658527] 88087f693d80 88087f6898c8 8107c1fa
>>> 00017f6898b8
>>> [ 65.666830] Call Trace:
>>> [ 65.669557] <#MC> [] dump_stack+0x46/0x58
>>> [ 65.675994] [] dequeue_task_idle+0x2f/0x40
>>> [ 65.682412] [] dequeue_task+0x5a/0x80
>>> [ 65.688345] [] deactivate_task+0x23/0x30
>>> [ 65.694569] [] __schedule+0x580/0x7f0
>>> [ 65.700502] [] schedule_preempt_disabled+0x29/0x70
>>> [ 65.707696] [] __ww_mutex_lock_slowpath+0xb8/0x162
>>> [ 65.714891] [] __ww_mutex_lock+0x53/0x85
>>> [ 65.721125] [] drm_modeset_lock+0x3d/0x110 [drm]
>>> [ 65.728132] [] __drm_modeset_lock_all+0x8a/0x120
>>> [drm]
>>> [ 65.735721] [] drm_modeset_lock_all+0x10/0x30 [drm]
>>> [ 65.743015] []
>>> drm_fb_helper_pan_display+0x2f/0xf0 [drm_kms_helper]
>>> [ 65.751857] [] fb_pan_display+0xd1/0x1a0
>>> [ 65.758081] [] bit_update_start+0x20/0x50
>>> [ 65.764400] [] fbcon_switch+0x3a2/0x550
>>> [ 65.770528] [] redraw_screen+0x189/0x240
>>> [ 65.776750] [] fbcon_blank+0x20a/0x2d0
>>> [ 65.782778] [] ? erst_writer+0x209/0x330
>>> [ 65.789002] [] ? internal_add_timer+0x63/0x80
>>> [ 65.795710] [] ? mod_timer+0x127/0x1e0
>>> [ 65.801740] [] do_unblank_screen+0xa8/0x1d0
>>> [ 65.808255] [] unblank_screen+0x10/0x20
>>> [ 65.814381] [] bust_spinlocks+0x19/0x40
>>> [ 65.820508] [] panic+0x106/0x1f5
>>> [ 65.825955] [] mce_panic+0x2ac/0x2e0
>>> [ 65.831789] [] ? delay_tsc+0x4a/0x80
>>> [ 65.837625] [] do_machine_check+0xbaf/0xbf0
>>> [ 65.844138] [] ? intel_idle+0xc7/0x150
>>> [ 65.850166] [] machine_check+0x1f/0x30
>>> [ 65.856195] [] ? intel_idle+0xc7/0x150
>>> [ 65.86] <> []
>>> cpuidle_enter_state+0x55/0x170
>>> [ 65.869823] [] cpuidle_enter+0x17/0x20
>>> [ 65.875852] [] cpu_startup_entry+0x2d8/0x370
>>> [ 65.882467] [] start_secondary+0x159/0x180
>>>
>>> There's __drm_modeset_lock_all() which Daniel Vetter introduced for this
>>> purpose. We can leverage that without reinventing anything. This patch
>>> works with the latest kernel.
>>>
>>> Signed-off-by: Rui Wang
>>> ---
>>> drivers/gpu/drm/drm_fb_helper.c |8 ++--
>>> 1 files changed, 6 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_fb_helper.c
>>> b/drivers/gpu/drm/drm_fb_helper.c
>>> index 0c0c39b..70dd2f4 100644
>>> --- a/drivers/gpu/drm/drm_fb_helper.c
>>> +++ b/drivers/gpu/drm/drm_fb_helper.c
>>> @@ -732,7 +732,9 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap,
>>> struct fb_info *info)
>>> int i, j, rc = 0;
>>> int start;
>>>
>>> - drm_modeset_lock_all(dev);
>>> + if (__drm_modeset_lock_all(dev, !!oops_in_progress)) {
>>> + return -EBUSY;
>>> + }
>>> if (!drm_fb_helper_is_bound(fb_helper)) {
>>> drm_modeset_unlock_all(dev);
>>> return -EBUSY;
>>> @@ -910,7 +912,9 @@ int drm_fb_helper_pan_display(struct fb_var_screeninfo
>>> *var,
>>> int ret = 0;
>>> int i;
>>>
>>> - drm_modeset_lock_all(dev);
>>> + if (__drm_modeset_lock_all(dev, !!oops_in_progress)) {
>>> + return -EBUSY;
>>> + }
>>> if (!drm_fb_helper_is_bound(fb_helper)) {
>>> drm_modeset_unlock_all(dev);
>>> return -EBUSY;
>>> --
>>> 1.7.5.4
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
>>> in
>>> the body of a messag
[PATCH] drm: fb helper should avoid sleeping in panic context
perhaps fb helpers could use __drm_modeset_lock_all() w/ trylock=true
in panic context?
BR,
-R
On Tue, Dec 9, 2014 at 7:09 PM, rui wang wrote:
> Hi All,
>
> Any comment ? Or any better idea how this should be fixed?
>
> Regards,
> Rui
>
> -- Forwarded message --
> From: ruiv.wang at gmail.com
> Date: Thu, 4 Dec 2014 22:11:35 +0800
> Subject: [PATCH] drm: fb helper should avoid sleeping in panic context
> To: airlied at redhat.com, daniel.vetter at ffwll.ch, tony.luck at intel.com,
> bp at alien8.de, aris at redhat.com, rui.y.wang at intel.com
> Cc: linux-kernel at vger.kernel.org
>
> From: Rui Wang
>
> There are still some places in the fb helper that need to avoid
> sleeping in panic context. Here's an example:
>
> [ 65.615496] bad: scheduling from the idle thread!
> [ 65.620747] CPU: 92 PID: 0 Comm: swapper/92 Tainted: G ME
> 3.18.0-rc4-7-default+ #20
>
> [ 65.630364] Hardware name: Intel Corporation BRICKLAND/BRICKLAND,
> BIOS BRHSXSD1.86B.0056.R01.1409242327 09/24/2014
> [ 65.641923] 88087f693d80 88087f689878 81566db9
>
> [ 65.650226] 88087f693d80 88087f689898 810871ff
> 88046eb3e0d0
> [ 65.658527] 88087f693d80 88087f6898c8 8107c1fa
> 00017f6898b8
> [ 65.666830] Call Trace:
> [ 65.669557] <#MC> [] dump_stack+0x46/0x58
> [ 65.675994] [] dequeue_task_idle+0x2f/0x40
> [ 65.682412] [] dequeue_task+0x5a/0x80
> [ 65.688345] [] deactivate_task+0x23/0x30
> [ 65.694569] [] __schedule+0x580/0x7f0
> [ 65.700502] [] schedule_preempt_disabled+0x29/0x70
> [ 65.707696] [] __ww_mutex_lock_slowpath+0xb8/0x162
> [ 65.714891] [] __ww_mutex_lock+0x53/0x85
> [ 65.721125] [] drm_modeset_lock+0x3d/0x110 [drm]
> [ 65.728132] [] __drm_modeset_lock_all+0x8a/0x120 [drm]
> [ 65.735721] [] drm_modeset_lock_all+0x10/0x30 [drm]
> [ 65.743015] []
> drm_fb_helper_pan_display+0x2f/0xf0 [drm_kms_helper]
> [ 65.751857] [] fb_pan_display+0xd1/0x1a0
> [ 65.758081] [] bit_update_start+0x20/0x50
> [ 65.764400] [] fbcon_switch+0x3a2/0x550
> [ 65.770528] [] redraw_screen+0x189/0x240
> [ 65.776750] [] fbcon_blank+0x20a/0x2d0
> [ 65.782778] [] ? erst_writer+0x209/0x330
> [ 65.789002] [] ? internal_add_timer+0x63/0x80
> [ 65.795710] [] ? mod_timer+0x127/0x1e0
> [ 65.801740] [] do_unblank_screen+0xa8/0x1d0
> [ 65.808255] [] unblank_screen+0x10/0x20
> [ 65.814381] [] bust_spinlocks+0x19/0x40
> [ 65.820508] [] panic+0x106/0x1f5
> [ 65.825955] [] mce_panic+0x2ac/0x2e0
> [ 65.831789] [] ? delay_tsc+0x4a/0x80
> [ 65.837625] [] do_machine_check+0xbaf/0xbf0
> [ 65.844138] [] ? intel_idle+0xc7/0x150
> [ 65.850166] [] machine_check+0x1f/0x30
> [ 65.856195] [] ? intel_idle+0xc7/0x150
> [ 65.86] <> [] cpuidle_enter_state+0x55/0x170
> [ 65.869823] [] cpuidle_enter+0x17/0x20
> [ 65.875852] [] cpu_startup_entry+0x2d8/0x370
> [ 65.882467] [] start_secondary+0x159/0x180
>
> There's __drm_modeset_lock_all() which Daniel Vetter introduced for this
> purpose. We can leverage that without reinventing anything. This patch
> works with the latest kernel.
>
> Signed-off-by: Rui Wang
> ---
> drivers/gpu/drm/drm_fb_helper.c |8 ++--
> 1 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 0c0c39b..70dd2f4 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -732,7 +732,9 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap,
> struct fb_info *info)
> int i, j, rc = 0;
> int start;
>
> - drm_modeset_lock_all(dev);
> + if (__drm_modeset_lock_all(dev, !!oops_in_progress)) {
> + return -EBUSY;
> + }
> if (!drm_fb_helper_is_bound(fb_helper)) {
> drm_modeset_unlock_all(dev);
> return -EBUSY;
> @@ -910,7 +912,9 @@ int drm_fb_helper_pan_display(struct fb_var_screeninfo
> *var,
> int ret = 0;
> int i;
>
> - drm_modeset_lock_all(dev);
> + if (__drm_modeset_lock_all(dev, !!oops_in_progress)) {
> + return -EBUSY;
> + }
> if (!drm_fb_helper_is_bound(fb_helper)) {
> drm_modeset_unlock_all(dev);
> return -EBUSY;
> --
> 1.7.5.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
[Bug 34969] [nouveau] Card lockup on openarena
https://bugs.freedesktop.org/show_bug.cgi?id=34969 Pierre Moreau changed: What|Removed |Added Status|NEW |NEEDINFO Component|DRM/other |Driver/nouveau Version|XOrg git|unspecified Assignee|dri-devel at lists.freedesktop |nouveau at lists.freedesktop.o |.org|rg Product|DRI |xorg QA Contact||xorg-team at lists.x.org --- Comment #21 from Pierre Moreau --- Moving to Nouveau. Are you still experiencing this issue with an updated graphic stack, aka. kernel 3.18, mesa 10.4, libdrm 2.4.58 and f86-video-nouveau 1.0.11? -- 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/20141209/b8ae3b63/attachment-0001.html>
[Bug 63192] [nouveau] drmModeSetCursor->nouveau_bo_rd32->ioread32 provides high cpu load when using weston drm-compositor
https://bugs.freedesktop.org/show_bug.cgi?id=63192 Pierre Moreau changed: What|Removed |Added Status|NEW |NEEDINFO Component|DRM/other |Driver/nouveau Version|DRI git |unspecified Assignee|dri-devel at lists.freedesktop |nouveau at lists.freedesktop.o |.org|rg Product|DRI |xorg QA Contact||xorg-team at lists.x.org --- Comment #1 from Pierre Moreau --- Moving to Nouveau. Are you still experiencing this issue with an updated graphic stack, aka. kernel 3.18, mesa 10.4, libdrm 2.4.58 and waylaid/weston 1.6? (The bug went unnoticed as it wasn't linked to Nouveau.) -- 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/20141209/aa333bd3/attachment.html>
[Bug 82714] nouveau: fails to properly initialize GPU
https://bugs.freedesktop.org/show_bug.cgi?id=82714 Pierre Moreau changed: What|Removed |Added Status|NEW |NEEDINFO Component|DRM/other |Driver/nouveau Version|XOrg git|unspecified Assignee|dri-devel at lists.freedesktop |nouveau at lists.freedesktop.o |.org|rg Product|DRI |xorg QA Contact||xorg-team at lists.x.org --- Comment #1 from Pierre Moreau --- Moving to Nouveau. Is this still an issue with kernel 3.18? (The bug went unnoticed as it wasn't linked to Nouveau.) -- 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/20141209/9c2259f6/attachment.html>
[PATCH v2 3/3] ARM: dts: add Panel device support for exynos3250-rinato
From: Inki Dae
This patch adds MIPI-DSI and MIPI-DSI based S6E63J0X03 AMOLED panel
device nodes for Exynos3250 Rinato board.
Signed-off-by: Inki Dae
Signed-off-by: Hyungwon Hwang
Acked-by: Kyungmin Park
---
Changes for v2:
- None
arch/arm/boot/dts/exynos3250-rinato.dts | 60 +
1 file changed, 60 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 79aa916..a8caee5 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -125,6 +125,66 @@
};
};
+&dsi_0 {
+ vddcore-supply = <&ldo6_reg>;
+ vddio-supply = <&ldo6_reg>;
+ samsung,pll-clock-frequency = <2400>;
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 1 {
+ reg = <1>;
+
+ dsi_out: endpoint {
+ remote-endpoint = <&dsi_in>;
+ samsung,burst-clock-frequency = <25000>;
+ samsung,esc-clock-frequency = <2000>;
+ };
+ };
+ };
+
+ panel at 0 {
+ compatible = "samsung,s6e63j0x03";
+ reg = <0>;
+ vdd3-supply = <&ldo16_reg>;
+ vci-supply = <&ldo20_reg>;
+ reset-gpios = <&gpe0 1 0>;
+ te-gpios = <&gpx0 6 0>;
+ power-on-delay= <30>;
+ power-off-delay= <120>;
+ reset-delay = <5>;
+ init-delay = <100>;
+ flip-horizontal;
+ flip-vertical;
+ panel-width-mm = <29>;
+ panel-height-mm = <29>;
+
+
+ display-timings {
+ timing-0 {
+ clock-frequency = <0>;
+ hactive = <320>;
+ vactive = <320>;
+ hfront-porch = <1>;
+ hback-porch = <1>;
+ hsync-len = <1>;
+ vfront-porch = <150>;
+ vback-porch = <1>;
+ vsync-len = <2>;
+ };
+ };
+
+ port {
+ dsi_in: endpoint {
+ remote-endpoint = <&dsi_out>;
+ };
+ };
+ };
+};
+
&fimd {
status = "okay";
--
1.9.1
[PATCH v2 2/3] drm/panel: add s6e63j0x03 LCD panel driver
From: Inki Dae
This patch adds MIPI-DSI based S6E63J0X03 AMOLED LCD panel driver
which uses mipi_dsi bus to communicate with panel. The panel has
320Ã320 resolution in 1.63-inch physical panel. This panel is used in
Samsung Galaxy Gear 2.
Signed-off-by: Inki Dae
Signed-off-by: Hyungwon Hwang
Acked-by: Kyungmin Park
---
Changes for v2:
- Change the gamma table to 2-dimensional array
- Change the way to make index for brightness
- Make command functions to an array so that it can be called simply
- Change command id for reading device ID
- Change the way to handle the error condition
- Remove power variable, and use the same name variable in bl_dev
- Add the state FB_BLANK_NORMAL to represent the state which the panel
is working but blanked
- Miscellaneous changes to increase the readability and follow the
coding-style standard
drivers/gpu/drm/panel/Kconfig| 6 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-s6e63j0x03.c | 549 +++
3 files changed, 556 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-s6e63j0x03.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index bee9f72..bc133e2 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -27,4 +27,10 @@ config DRM_PANEL_S6E8AA0
select DRM_MIPI_DSI
select VIDEOMODE_HELPERS
+config DRM_PANEL_S6E63J0X03
+ tristate "S6E63J0X03 DSI video mode panel"
+ depends on OF
+ select DRM_MIPI_DSI
+ select VIDEOMODE_HELPERS
+
endmenu
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 8b92921..7f36dc2 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
obj-$(CONFIG_DRM_PANEL_LD9040) += panel-ld9040.o
obj-$(CONFIG_DRM_PANEL_S6E8AA0) += panel-s6e8aa0.o
+obj-$(CONFIG_DRM_PANEL_S6E63J0X03) += panel-s6e63j0x03.o
diff --git a/drivers/gpu/drm/panel/panel-s6e63j0x03.c
b/drivers/gpu/drm/panel/panel-s6e63j0x03.c
new file mode 100644
index 000..28e4a51
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-s6e63j0x03.c
@@ -0,0 +1,549 @@
+/*
+ * MIPI-DSI based S6E63J0X03 AMOLED lcd 1.63 inch panel driver.
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd
+ *
+ * Inki Dae,
+ *
+ * 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
+
+#define READ_ID1 0xDA
+#define READ_ID2 0xDB
+#define READ_ID3 0xDC
+
+#define MCS_LEVEL2_KEY 0xf0
+#define MCS_MTP_KEY0xf1
+#define MCS_MTP_SET3 0xd4
+
+#define MIN_BRIGHTNESS 0
+#define MAX_BRIGHTNESS 100
+#define DEFAULT_BRIGHTNESS 80
+
+#define GAMMA_LEVEL_NUM30
+#define NUM_GAMMA_STEPS9
+#define GAMMA_CMD_CNT 28
+
+struct s6e63j0x03 {
+ struct device *dev;
+ struct drm_panel panel;
+ struct backlight_device *bl_dev;
+
+ struct regulator_bulk_data supplies[2];
+ struct gpio_desc *reset_gpio;
+ u32 power_on_delay;
+ u32 power_off_delay;
+ u32 reset_delay;
+ u32 init_delay;
+ bool flip_horizontal;
+ bool flip_vertical;
+ struct videomode vm;
+ unsigned int width_mm;
+ unsigned int height_mm;
+};
+
+static const unsigned char gamma_tbl[NUM_GAMMA_STEPS][GAMMA_CMD_CNT] = {
+ { /* Gamma 10 */
+ MCS_MTP_SET3,
+ 0x00, 0x00, 0x00, 0x7f, 0x7f, 0x7f, 0x52, 0x6b, 0x6f, 0x26,
+ 0x28, 0x2d, 0x28, 0x26, 0x27, 0x33, 0x34, 0x32, 0x36, 0x36,
+ 0x35, 0x00, 0xab, 0x00, 0xae, 0x00, 0xbf
+ },
+ { /* gamma 30 */
+ MCS_MTP_SET3,
+ 0x00, 0x00, 0x00, 0x70, 0x7f, 0x7f, 0x4e, 0x64, 0x69, 0x26,
+ 0x27, 0x2a, 0x28, 0x29, 0x27, 0x31, 0x32, 0x31, 0x35, 0x34,
+ 0x35, 0x00, 0xc4, 0x00, 0xca, 0x00, 0xdc
+ },
+ { /* gamma 60 */
+ MCS_MTP_SET3,
+ 0x00, 0x00, 0x00, 0x65, 0x7b, 0x7d, 0x5f, 0x67, 0x68, 0x2a,
+ 0x28, 0x29, 0x28, 0x2a, 0x27, 0x31, 0x2f, 0x30, 0x34, 0x33,
+ 0x34, 0x00, 0xd9, 0x00, 0xe4, 0x00, 0xf5
+ },
+ { /* gamma 90 */
+ MCS_MTP_SET3,
+ 0x00, 0x00, 0x00, 0x4d, 0x6f, 0x71, 0x67, 0x6a, 0x6c, 0x29,
+ 0x28, 0x28, 0x28, 0x29, 0x27, 0x30, 0x2e, 0x30, 0x32, 0x31,
+ 0x31, 0x00, 0xea, 0x00, 0xf6, 0x01, 0x09
+ },
+ { /* gamma 120 */
+ MCS_MTP_SET3,
+ 0x00, 0x00, 0x00, 0x3d, 0x66, 0x68, 0x69, 0x69, 0x69, 0x28,
+ 0x28, 0x27, 0x28, 0x28, 0x27, 0x30, 0x2e, 0x2f, 0
[PATCH v2 1/3] ARM: dts: add fimd device support for exynos3250-rinato
From: Inki Dae
This patch adds fimd device node which is a display controller
for Exynos3250 Rinato board.
Signed-off-by: Inki Dae
Signed-off-by: Hyungwon Hwang
Acked-by: Kyungmin Park
---
Changes for v2:
- None
arch/arm/boot/dts/exynos3250-rinato.dts | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 80aa8b4..79aa916 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -125,6 +125,17 @@
};
};
+&fimd {
+ status = "okay";
+
+ i80-if-timings {
+ cs-setup = <0>;
+ wr-setup = <0>;
+ wr-act = <1>;
+ wr-hold = <0>;
+ };
+};
+
&i2c_0 {
#address-cells = <1>;
#size-cells = <0>;
--
1.9.1
[PATCH v2 0/3] add display support for exynos3250 rinato board
This is v2 of the patchset adding support for s6e63j0x03 lcd panel. Inki Dae sent this patchset before. Because of his busy work at company, I modifies some point according to the review by Thierry Reding on behalf of him. This patch series adds Display support for exynos3250 Rinato board. For this, it adds fimd, MIPI-DSI and Panel device nodes to exynos3250-rinato dts file, and adds a s6e63j0x03 Amoled panel device driver which is based on MIPI-DSI bus. Changes for v2: - Change the gamma table to 2-dimensional array - Change the way to make index for brightness - Make command functions to an array so that it can be called simply - Change command id for reading device ID - Change the way to handle the error condition - Remove power variable, and use the same name variable in bl_dev - Add the state FB_BLANK_NORMAL to represent the state which the panel is working but blanked - Miscellaneous changes to increase the readability and follow the coding-style standard Inki Dae (3): ARM: dts: add fimd device support for exynos3250-rinato drm/panel: add s6e63j0x03 LCD panel driver ARM: dts: add Panel device support for exynos3250-rinato arch/arm/boot/dts/exynos3250-rinato.dts | 71 drivers/gpu/drm/panel/Kconfig| 6 + drivers/gpu/drm/panel/Makefile | 1 + drivers/gpu/drm/panel/panel-s6e63j0x03.c | 549 +++ 4 files changed, 627 insertions(+) create mode 100644 drivers/gpu/drm/panel/panel-s6e63j0x03.c -- 1.9.1
[Bug 57352] [nouveau] Kernel Tux logo incorrectly displayed at boot
https://bugs.freedesktop.org/show_bug.cgi?id=57352 Pierre Moreau changed: What|Removed |Added Status|NEW |NEEDINFO Component|DRM/other |Driver/nouveau Hardware|Other |x86-64 (AMD64) Version|XOrg git|unspecified Assignee|dri-devel at lists.freedesktop |nouveau at lists.freedesktop.o |.org|rg Product|DRI |xorg QA Contact||xorg-team at lists.x.org --- Comment #2 from Pierre Moreau --- Moving to Nouveau. This issue should be fixed by now, but could you still please test with a recent kernel? You will need patch v4.5 listed in bug #27501 if you want to use acceleration on that card. Otherwise, set nouveau.noaccel=1 and you should be fine. -- 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/20141209/1e2d0401/attachment.html>
Long radeon stalls on recent kernels
On 09.12.2014 09:24, Andy Lutomirski wrote: > > The relevant line from latencytop seems to be: > > 154 20441402 489139 radeon_fence_default_wait [radeon] > fence_wait_timeout ttm_bo_wait [ttm] ttm_bo_move_accel_cleanup [ttm] > radeon_move_blit.isra.12 [radeon] radeon_bo_move [radeon] > ttm_bo_handle_move_mem [ttm] ttm_bo_evict [ttm] ttm_mem_evict_first > [ttm] ttm_bo_mem_space [ttm] ttm_bo_validate [ttm] > radeon_bo_fault_reserve_notify [radeon] Which process is this? Looks like CPU access to a BO in VRAM, but the BO is located outside of the CPU visible area of VRAM, so it has to be moved into the CPU visible area first. Which version of Mesa are you using? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
[Bug 34296] Failure loading nouveau for nVidia GeForce 8600 GT on ASUS XG Station(external 1x PCIe encasing for an GPU)
https://bugs.freedesktop.org/show_bug.cgi?id=34296 Pierre Moreau changed: What|Removed |Added Status|NEW |NEEDINFO Component|DRM/other |Driver/nouveau Version|XOrg git|unspecified Assignee|dri-devel at lists.freedesktop |nouveau at lists.freedesktop.o |.org|rg Product|DRI |xorg QA Contact||xorg-team at lists.x.org --- Comment #4 from Pierre Moreau --- Moving to Nouveau. Could you please retest with a recent kernel? (The bug went unnoticed as it wasn't linked to Nouveau.) -- 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/20141209/1888e8b0/attachment.html>
[PATCH 3/6] drm/radeon: add command submission IDs
On 09.12.2014 01:11, Christian König wrote: > From: Christian König > > This patch adds a new 64bit ID as a result to each command submission. > > Signed-off-by: Christian König I noticed a few spelling mistakes, see below. Other than these minor nits, I haven't noticed any problems in this series, though I haven't looked at it in too much detail. > +/* > + * ID sequences > + * This code generates a 64bit identifier for a command submission. > + * It works by adding the fence of the command submission to a automatically 'to an automatically' > +/** > + * radeon_seq_query - lockup fence by it's ID 'look up fence by its ID' > + * @seq: sequence object > + * @id: the generated ID > + * > + * Lockup the associated fence by it's ID. 'Look up the associated fence by its ID.' > +/* The fourth and fives dword are a 64bit fence ID generated for this CS */ 'fourth and fifth' -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
[PATCH 4/6] drm/radeon: add explicit command submission sync
On 09.12.2014 01:11, Christian König wrote: > From: Christian König > > The driver falls back to explicit synchronization as soon as > buffers move between clients or are moved by TTM. I assume this should say 'falls back to implicit synchronization'. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
[Bug 28095] X crash with PFIFO_CACHE_ERROR. (Nouveau on Riva TNT).
https://bugs.freedesktop.org/show_bug.cgi?id=28095 Pierre Moreau changed: What|Removed |Added Status|NEW |NEEDINFO Component|DRM/other |Driver/nouveau Assignee|dri-devel at lists.freedesktop |nouveau at lists.freedesktop.o |.org|rg Product|DRI |xorg QA Contact||xorg-team at lists.x.org --- Comment #2 from Pierre Moreau --- Moving to Nouveau. Could you please retest with a recent kernel? (The bug went unnoticed as it wasn't linked to Nouveau.) -- 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/20141209/4dac038a/attachment-0001.html>
[Bug 81690] nouveau GPU locks up under memory pressure
https://bugs.freedesktop.org/show_bug.cgi?id=81690 Pierre Moreau changed: What|Removed |Added Component|DRM/other |Driver/nouveau Assignee|dri-devel at lists.freedesktop |nouveau at lists.freedesktop.o |.org|rg Product|DRI |xorg QA Contact||xorg-team at lists.x.org --- Comment #2 from Pierre Moreau --- Correcting product and component to link it to Nouveau. -- 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/20141209/2175a263/attachment.html>
[Bug 60879] [radeonsi] X11 can't start with acceleration enabled
https://bugs.freedesktop.org/show_bug.cgi?id=60879 --- Comment #113 from Alex Deucher --- (In reply to madcatx from comment #112) > Is there any chance of this getting backported to stable 10.3 series? The v5 > fix works fine for me with 10.3.3. Yes, it should show up in the stable releases. From the commit message: CC: "10.4 10.3" -- 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/20141209/f3c1f1f2/attachment.html>
[Bug 60879] [radeonsi] X11 can't start with acceleration enabled
https://bugs.freedesktop.org/show_bug.cgi?id=60879 --- Comment #112 from madcatx at atlas.cz --- Is there any chance of this getting backported to stable 10.3 series? The v5 fix works fine for me with 10.3.3. -- 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/20141209/b059b177/attachment.html>
drm/exynos: some small forgotten patch
On 2014-12-09 13:09, Inki Dae wrote: > That might be a patch I missed. Can you tell me the Subject? Uhm, I think that is obvious from the mail? http://www.spinics.net/lists/linux-samsung-soc/msg39811.html Anyway, I'm still waiting for Thierry's reply on that matter. With best wishes, Tobias
[Bug 60879] [radeonsi] X11 can't start with acceleration enabled
https://bugs.freedesktop.org/show_bug.cgi?id=60879 Pali Rohár changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #111 from Pali Rohár --- Looks like patch was commited to mesa git: http://cgit.freedesktop.org/mesa/mesa/commit/?id=67dcbcd92cb9877a04747d6cf7fef14c2b8af8b3 -- 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/20141209/2d10cc34/attachment.html>
[PATCH] drm/dp-mst: Remove branches before dropping the reference
> On 8 December 2014 at 22:55, Daniel Vetter wrote:
> > When we unplug a dp mst branch we unreference the entire tree from
> > the root towards the leaves. Which is ok, since that's the way the
> > pointers and so also the refcounts go.
> >
> > But when we drop the reference we must make sure that we remove the
> > branches/ports from the lists/pointers before dropping the reference.
> > Otherwise the get_validated functions will still return it instead
> > of returning NULL (which indicates a potentially on-going unplug).
> >
> > The mst branch destroy gets this right for ports: First it deletes
> > the port from the ports list, then it unrefs. But the ports destroy
> > function gets it wrong: First it unrefs, then it drops the ref. Which
> > means a zombie mst branch can still be validate with get_validated_mstb_ref
> > when it shouldn't.
> >
> > Fix this.
> >
> > This should address a backtrace Dave dug out somewhere on unplug:
> >
> > [] drm_dp_mst_get_validated_mstb_ref_locked+0x92/0xa0
> > [drm_kms_helper]
> > [] drm_dp_mst_get_validated_mstb_ref_locked+0x41/0xa0
> > [drm_kms_helper]
> > [] drm_dp_get_validated_mstb_ref+0x3a/0x60
> > [drm_kms_helper]
> > [] drm_dp_payload_send_msg.isra.14+0x2b/0x100
> > [drm_kms_helper]
> > [] drm_dp_update_payload_part1+0x177/0x360
> > [drm_kms_helper]
> > [] intel_mst_disable_dp+0x3e/0x80 [i915]
> > [] haswell_crtc_disable+0x1cb/0x340 [i915]
> > [] intel_crtc_control+0x49/0x100 [i915]
> > [] intel_crtc_update_dpms+0x67/0x80 [i915]
> > [] intel_connector_dpms+0x59/0x70 [i915]
> > [] intel_dp_destroy_mst_connector+0x32/0xc0 [i915]
> > [] drm_dp_destroy_port+0x6b/0xa0 [drm_kms_helper]
> > [] drm_dp_destroy_mst_branch_device+0x108/0x130
> > [drm_kms_helper]
> > [] drm_dp_port_teardown_pdt+0x3d/0x50 [drm_kms_helper]
> > [] drm_dp_mst_handle_up_req+0x499/0x540 [drm_kms_helper]
> > [] ? trace_hardirqs_on_caller+0x15d/0x200
> > []
> > drm_dp_mst_hpd_irq+0x53/0xa00 [drm_kms_helper] []
> > ? drm_dp_dpcd_read+0x1b/0x20 [drm_kms_helper] []
> > ? intel_dp_dpcd_read_wake+0x38/0x70 [i915] []
> > intel_dp_check_mst_status+0xb5/0x250 [i915] []
> > intel_dp_hpd_pulse+0x181/0x210 [i915] []
> > i915_digport_work_func+0x96/0x120 [i915]
> >
> > Cc: Dave Airlie
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_dp_mst_topology.c | 5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index 5682d7e9f1ec..71a56d65a0d2 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -839,6 +839,8 @@ static void drm_dp_put_mst_branch_device(struct
> > drm_dp_mst_branch *mstb)
> >
> > static void drm_dp_port_teardown_pdt(struct drm_dp_mst_port *port, int
> > old_pdt)
> > {
> > + struct drm_dp_mst_branch *mstb;
> > +
> > switch (old_pdt) {
> > case DP_PEER_DEVICE_DP_LEGACY_CONV:
> > case DP_PEER_DEVICE_SST_SINK:
> > @@ -846,8 +848,9 @@ static void drm_dp_port_teardown_pdt(struct
> > drm_dp_mst_port *port, int old_pdt)
> > drm_dp_mst_unregister_i2c_bus(&port->aux);
> > break;
> > case DP_PEER_DEVICE_MST_BRANCHING:
> > - drm_dp_put_mst_branch_device(port->mstb);
> > + mstb = port_mstb;
>
> drivers/gpu/drm/drm_dp_mst_topology.c:851:10: error: âport_mstbâ
> undeclared
>
> This needs to be port->mstb. Spotted while testing this for
> https://bugs.freedesktop.org/show_bug.cgi?id=87099
The version I checked in fixed this.
Dave.
FOSDEM15: Graphics DevRoom: call for speakers.
On Thu, Oct 02, 2014 at 07:44:57PM +0200, Luc Verhaegen wrote: > Hi, > > At FOSDEM on the 31st of january and the 1st of February 2015, there > will be another graphics DevRoom. URL: https://fosdem.org/2015/ > Slots will be handed out on a first come, first serve basis. The best > slots will go to those who apply the earliest. The amount of slots is > currently not known yet, but i expect there to be around 16 available (8 > on each day), so act quickly. > As for deadlines, i hope to have a pretty much complete schedule between > christmas and the new year. The rockhard printed schedule deadline is > probably January 9th, after that you will not be featured in the booklet > and you will have a lot less visitors. I will hopefully be able to lock > down entries and descriptions after that date. It's been more than 2 months since the original email, it's less than two months away from the event, and one month away from what usually is the deadline for the booklet. File your talk now, while there are still some useful slots available. Also, for those who have filed already but who have left their abstracts open, please get those filed in ASAP. Your talk will be only be ordered in when at least the basics are provided. Thanks, Luc Verhaegen.
[Bug 89461] [Radeon - FirePro M7740] Dual screen fails with kernel version 3.17
https://bugzilla.kernel.org/show_bug.cgi?id=89461 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #1 from Alex Deucher --- Created attachment 160261 --> https://bugzilla.kernel.org/attachment.cgi?id=160261&action=edit possible fix The attached patch should fix it. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] drm/tegra: dsi: Add suspend/resume support
On Sun, Dec 7, 2014 at 10:40 PM, Mark Zhang wrote:
> This patch adds the suspend/resume support for Tegra drm
> driver by calling the corresponding DPMS functions.
>
> Signed-off-by: Mark Zhang
> ---
> Hi,
>
> This patch hooks DSI driver's suspend/resume to implement the whole
> display system's suspend/resume. I know this is a super ugly way,
> but as we all know, Tegra DRM driver doesn't have a dedicate drm device
> so honestly I didn't find a better way to do that.
>
> Thanks,
> Mark
>
Hi Mark,
Thanks for posting this. I've reproduced my Gerrit comments from the
CrOS tree below for the benefit of others.
> drivers/gpu/drm/tegra/dsi.c | 96
> ++---
> 1 file changed, 90 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/tegra/dsi.c b/drivers/gpu/drm/tegra/dsi.c
> index 33f67fd601c6..25cd0d93f392 100644
> --- a/drivers/gpu/drm/tegra/dsi.c
> +++ b/drivers/gpu/drm/tegra/dsi.c
> @@ -61,6 +61,9 @@ struct tegra_dsi {
> struct tegra_dsi *slave;
> };
>
> +static int tegra_dsi_pad_calibrate(struct tegra_dsi *);
> +static int tegra_dsi_ganged_setup(struct tegra_dsi *dsi);
> +
> static inline struct tegra_dsi *
> host1x_client_to_dsi(struct host1x_client *client)
> {
> @@ -805,6 +808,20 @@ static int tegra_output_dsi_setup_clock(struct
> tegra_output *output,
>
> lanes = tegra_dsi_get_lanes(dsi);
>
> + err = tegra_dsi_pad_calibrate(dsi);
> + if (err < 0) {
> + dev_err(dsi->dev, "MIPI calibration failed: %d\n", err);
> + return err;
> + }
> + if (dsi->slave) {
> + err = tegra_dsi_pad_calibrate(dsi->slave);
> + if (err < 0) {
> + dev_err(dsi->slave->dev,
> + "MIPI calibration failed: %d\n", err);
> + return err;
> + }
> + }
Move this duplicate call into tegra_dsi_pad_calibrate() to be
consistent with the other functions in this file (eg:
tegra_dsi_set_timeout).
> +
> err = tegra_dsi_get_muldiv(dsi->format, &mul, &div);
> if (err < 0)
> return err;
> @@ -833,6 +850,13 @@ static int tegra_output_dsi_setup_clock(struct
> tegra_output *output,
> dev_err(dsi->dev, "failed to set parent clock: %d\n", err);
> return err;
> }
> + if (dsi->slave) {
> + err = tegra_dsi_ganged_setup(dsi);
> + if (err < 0) {
> + dev_err(dsi->dev, "DSI ganged setup failed: %d\n",
> err);
> + return err;
> + }
> + }
I think this belongs in ->enable() instead of here.
>
> err = clk_set_rate(dsi->clk_parent, plld);
> if (err < 0) {
> @@ -1470,12 +1494,6 @@ static int tegra_dsi_probe(struct platform_device
> *pdev)
> goto disable_vdd;
> }
>
> - err = tegra_dsi_pad_calibrate(dsi);
> - if (err < 0) {
> - dev_err(dsi->dev, "MIPI calibration failed: %d\n", err);
> - goto mipi_free;
> - }
> -
> dsi->host.ops = &tegra_dsi_host_ops;
> dsi->host.dev = &pdev->dev;
>
> @@ -1544,6 +1562,67 @@ static int tegra_dsi_remove(struct platform_device
> *pdev)
> return 0;
> }
>
> +#ifdef CONFIG_PM
> +static int tegra_dsi_suspend(struct platform_device *pdev, pm_message_t
> state)
> +{
> + struct tegra_dsi *dsi = platform_get_drvdata(pdev);
> + struct tegra_drm *tegra = dev_get_drvdata(dsi->client.parent);
> + struct drm_connector *connector;
> +
> + if (dsi->master) {
> + regulator_disable(dsi->vdd);
> + return 0;
> + }
> +
> + drm_modeset_lock_all(tegra->drm);
> + list_for_each_entry(connector,
> &tegra->drm->mode_config.connector_list,
> + head) {
> + int old_dpms = connector->dpms;
> +
> + if (connector->funcs->dpms)
> + connector->funcs->dpms(connector, DRM_MODE_DPMS_OFF);
> +
> + /* Set the old mode back to the connector for resume */
> + connector->dpms = old_dpms;
> + }
> + drm_modeset_unlock_all(tegra->drm);
> +
> + regulator_disable(dsi->vdd);
> +
> + return 0;
> +}
> +
> +static int tegra_dsi_resume(struct platform_device *pdev)
> +{
> + struct tegra_dsi *dsi = platform_get_drvdata(pdev);
> + struct tegra_drm *tegra = dev_get_drvdata(dsi->client.parent);
> + struct drm_connector *connector;
> + int err = 0;
> +
> + err = regulator_enable(dsi->vdd);
> + if (err < 0) {
> + dev_err(&pdev->dev, "Enable DSI vdd failed: %d\n", err);
> + return err;
> + }
> +
> + if (dsi->master)
> + return 0;
> +
> + drm_modeset_lock_all(tegra->drm);
> + list_for_each_entry(connector,
> &tegra->drm->mode_config.connector_list,
> +
Long radeon stalls on recent kernels
On Tue, Dec 9, 2014 at 8:06 AM, Andy Lutomirski wrote: > On Tue, Dec 9, 2014 at 1:18 AM, Michel Dänzer wrote: >> On 09.12.2014 09:24, Andy Lutomirski wrote: >>> >>> The relevant line from latencytop seems to be: >>> >>> 154 20441402 489139 radeon_fence_default_wait [radeon] >>> fence_wait_timeout ttm_bo_wait [ttm] ttm_bo_move_accel_cleanup [ttm] >>> radeon_move_blit.isra.12 [radeon] radeon_bo_move [radeon] >>> ttm_bo_handle_move_mem [ttm] ttm_bo_evict [ttm] ttm_mem_evict_first >>> [ttm] ttm_bo_mem_space [ttm] ttm_bo_validate [ttm] >>> radeon_bo_fault_reserve_notify [radeon] >> >> Which process is this? > > Xorg > >> >> Looks like CPU access to a BO in VRAM, but the BO is located outside of >> the CPU visible area of VRAM, so it has to be moved into the CPU visible >> area first. >> >> Which version of Mesa are you using? >> > > mesa-dri-drivers-10.3.3-1.20141110.fc20.x86_64 > > I'm planning on upgrading to Fedora 21 fairly soon. Upgrading to mesa-dri-drivers-10.3.3-1.20141110.fc21.x86_64 seems to have helped enough that my usual test (open a couple of Firefox tabs with graphics in them) doesn't hang anymore. This card still isn't *fast*. Is there some way I can check that I'm actually using all 16 PCIe lanes? In my tinkering w/ power management settings, I got some odd logs suggesting that only one lane was in use. Other than that, maybe everything works :) But I'm still waiting for the day that buggy userspace *can't* cause kernel graphics stalls. --Andy > > --Andy > >> >> -- >> Earthling Michel Dänzer | http://www.amd.com >> Libre software enthusiast | Mesa and X developer > > > > -- > Andy Lutomirski > AMA Capital Management, LLC -- Andy Lutomirski AMA Capital Management, LLC
[PATCH] drm/dp: retry AUX transactions 32 times (v1.1)
On Tue, 09 Dec 2014, Dave Airlie wrote:
>> Missed this version, see my reply to v1:
>> http://mid.gmane.org/87k32iqppg.fsf at intel.com
>>
>> Also, what if you avoid sink dpms off with:
>>
>> diff --git a/drivers/gpu/drm/i915/intel_dp.c
>> b/drivers/gpu/drm/i915/intel_dp.c
>> index 70bb8d0b9695..768b1bfaea78 100644
>> --- a/drivers/gpu/drm/i915/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> @@ -1932,7 +1932,7 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp, int
>> mode)
>>
>> if (mode != DRM_MODE_DPMS_ON) {
>> ret = drm_dp_dpcd_writeb(&intel_dp->aux, DP_SET_POWER,
>> -DP_SET_POWER_D3);
>> +DP_SET_POWER_D0);
>> } else {
>> /*
>> * When turning on, we need to retry for 1ms to give the sink
>>
>> Does it make a difference?
>
> Meant to reply, but the sink is definitely out of dpms when hit this,
>
> I've already done a fair few dpcd transactions, and asked it to link train,
> It is mostly link training the downstream at that point that I think is making
> it defer.
Okay, ack on the patch then. I wish we had something better to base the
limit on, but if this makes it work, so be it.
BR,
Jani.
>
> Dave.
--
Jani Nikula, Intel Open Source Technology Center
[PATCH] drm: fix a typo in a comment
On Tue, Dec 09, 2014 at 08:13:09AM +0100, Martin Peres wrote: > Spotted while reviewing the DRM changes in Linux 3.18 for LinuxFR. > > Cc: Ville Syrjälä > Signed--off-by: Martin Peres Both merged to my drm-misc branch, thanks. -Daniel > --- > drivers/gpu/drm/drm_irq.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c > index 0e47df4..f5a5f18 100644 > --- a/drivers/gpu/drm/drm_irq.c > +++ b/drivers/gpu/drm/drm_irq.c > @@ -166,7 +166,7 @@ static void vblank_disable_and_save(struct drm_device > *dev, int crtc) > spin_lock_irqsave(&dev->vblank_time_lock, irqflags); > > /* > - * If the vblank interrupt was already disbled update the count > + * If the vblank interrupt was already disabled update the count >* and timestamp to maintain the appearance that the counter >* has been ticking all along until this time. This makes the >* count account for the entire time between drm_vblank_on() and > -- > 2.1.3 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] drm/radeon: fix sad_count check for dce3
Make it consistent with the sad code for other asics to deal
with monitors that don't report sads.
bug:
https://bugzilla.kernel.org/show_bug.cgi?id=89461
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/dce3_1_afmt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/dce3_1_afmt.c
b/drivers/gpu/drm/radeon/dce3_1_afmt.c
index 2fe8cfc..bafdf92 100644
--- a/drivers/gpu/drm/radeon/dce3_1_afmt.c
+++ b/drivers/gpu/drm/radeon/dce3_1_afmt.c
@@ -103,7 +103,7 @@ static void dce3_2_afmt_write_sad_regs(struct drm_encoder
*encoder)
}
sad_count = drm_edid_to_sad(radeon_connector->edid, &sads);
- if (sad_count < 0) {
+ if (sad_count <= 0) {
DRM_ERROR("Couldn't read SADs: %d\n", sad_count);
return;
}
--
1.8.3.1
[PATCH 1/2] drm/dp: retry AUX transactions 32 times
On 26 November 2014 at 19:24, Jani Nikula wrote: > On Wed, 26 Nov 2014, Dave Airlie wrote: >> From: Dave Airlie >> >> At least on two MST devices I've tested with, when >> they are link training downstream, they are totally >> unable to handle aux ch msgs, so they defer like nuts. >> I tried 16, it wasn't enough, 32 seems better. > > I think we have a bug with some dongle that defers a lot too. One idea > was to use a progressively longer delay for DP_AUX_NATIVE_REPLY_DEFER. > > How about drm_dp_i2c_do_msg(), that one can receive native aux defer > too, along with i2c defer. It feels like both places should have the > same limit for native aux defer, but if you want to keep different i2c > defer retry limit it gets a bit trickier. I think we want to keep the spec limit there, since its in the spec, But you might be right on wanting to extend the defer therre as well if we can, I'll probably tackle that in a second patch. Dave.
[PATCH] drm: fix a word repetition in a comment
On Tue, Dec 9, 2014 at 1:24 AM, Martin Peres wrote: > Spotted while reviewing the DRM changes in Linux 3.18 for LinuxFR. > > CC: Daniel Vetter > Signed-off-by: Martin Peres Reviewed-by: Alex Deucher > --- > drivers/gpu/drm/drm_crtc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c > index 4a44f89..90ad762 100644 > --- a/drivers/gpu/drm/drm_crtc.c > +++ b/drivers/gpu/drm/drm_crtc.c > @@ -3454,7 +3454,7 @@ void drm_fb_release(struct drm_file *priv) > > /* > * When the file gets released that means no one else can access the > fb > -* list any more, so no need to grab fpriv->fbs_lock. And we need to > to > +* list any more, so no need to grab fpriv->fbs_lock. And we need to > * avoid upsetting lockdep since the universal cursor code adds a > * framebuffer while holding mutex locks. > * > -- > 2.1.3 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/dp: retry AUX transactions 32 times (v1.1)
> Missed this version, see my reply to v1:
> http://mid.gmane.org/87k32iqppg.fsf at intel.com
>
> Also, what if you avoid sink dpms off with:
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 70bb8d0b9695..768b1bfaea78 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1932,7 +1932,7 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp, int
> mode)
>
> if (mode != DRM_MODE_DPMS_ON) {
> ret = drm_dp_dpcd_writeb(&intel_dp->aux, DP_SET_POWER,
> -DP_SET_POWER_D3);
> +DP_SET_POWER_D0);
> } else {
> /*
> * When turning on, we need to retry for 1ms to give the sink
>
> Does it make a difference?
Meant to reply, but the sink is definitely out of dpms when hit this,
I've already done a fair few dpcd transactions, and asked it to link train,
It is mostly link training the downstream at that point that I think is making
it defer.
Dave.
[PATCH] drm/dp-mst: Remove branches before dropping the reference
On 8 December 2014 at 22:55, Daniel Vetter wrote:
> When we unplug a dp mst branch we unreference the entire tree from
> the root towards the leaves. Which is ok, since that's the way the
> pointers and so also the refcounts go.
>
> But when we drop the reference we must make sure that we remove the
> branches/ports from the lists/pointers before dropping the reference.
> Otherwise the get_validated functions will still return it instead
> of returning NULL (which indicates a potentially on-going unplug).
>
> The mst branch destroy gets this right for ports: First it deletes
> the port from the ports list, then it unrefs. But the ports destroy
> function gets it wrong: First it unrefs, then it drops the ref. Which
> means a zombie mst branch can still be validate with get_validated_mstb_ref
> when it shouldn't.
>
> Fix this.
>
> This should address a backtrace Dave dug out somewhere on unplug:
>
> [] drm_dp_mst_get_validated_mstb_ref_locked+0x92/0xa0
> [drm_kms_helper]
> [] drm_dp_mst_get_validated_mstb_ref_locked+0x41/0xa0
> [drm_kms_helper]
> [] drm_dp_get_validated_mstb_ref+0x3a/0x60 [drm_kms_helper]
> [] drm_dp_payload_send_msg.isra.14+0x2b/0x100
> [drm_kms_helper]
> [] drm_dp_update_payload_part1+0x177/0x360 [drm_kms_helper]
> [] intel_mst_disable_dp+0x3e/0x80 [i915]
> [] haswell_crtc_disable+0x1cb/0x340 [i915]
> [] intel_crtc_control+0x49/0x100 [i915]
> [] intel_crtc_update_dpms+0x67/0x80 [i915]
> [] intel_connector_dpms+0x59/0x70 [i915]
> [] intel_dp_destroy_mst_connector+0x32/0xc0 [i915]
> [] drm_dp_destroy_port+0x6b/0xa0 [drm_kms_helper]
> [] drm_dp_destroy_mst_branch_device+0x108/0x130
> [drm_kms_helper]
> [] drm_dp_port_teardown_pdt+0x3d/0x50 [drm_kms_helper]
> [] drm_dp_mst_handle_up_req+0x499/0x540 [drm_kms_helper]
> [] ? trace_hardirqs_on_caller+0x15d/0x200
> []
> drm_dp_mst_hpd_irq+0x53/0xa00 [drm_kms_helper] []
> ? drm_dp_dpcd_read+0x1b/0x20 [drm_kms_helper] []
> ? intel_dp_dpcd_read_wake+0x38/0x70 [i915] []
> intel_dp_check_mst_status+0xb5/0x250 [i915] []
> intel_dp_hpd_pulse+0x181/0x210 [i915] []
> i915_digport_work_func+0x96/0x120 [i915]
>
> Cc: Dave Airlie
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 5682d7e9f1ec..71a56d65a0d2 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -839,6 +839,8 @@ static void drm_dp_put_mst_branch_device(struct
> drm_dp_mst_branch *mstb)
>
> static void drm_dp_port_teardown_pdt(struct drm_dp_mst_port *port, int
> old_pdt)
> {
> + struct drm_dp_mst_branch *mstb;
> +
> switch (old_pdt) {
> case DP_PEER_DEVICE_DP_LEGACY_CONV:
> case DP_PEER_DEVICE_SST_SINK:
> @@ -846,8 +848,9 @@ static void drm_dp_port_teardown_pdt(struct
> drm_dp_mst_port *port, int old_pdt)
> drm_dp_mst_unregister_i2c_bus(&port->aux);
> break;
> case DP_PEER_DEVICE_MST_BRANCHING:
> - drm_dp_put_mst_branch_device(port->mstb);
> + mstb = port_mstb;
drivers/gpu/drm/drm_dp_mst_topology.c:851:10: error: âport_mstbâ undeclared
This needs to be port->mstb. Spotted while testing this for
https://bugs.freedesktop.org/show_bug.cgi?id=87099
> port->mstb = NULL;
> + drm_dp_put_mst_branch_device(mstb);
> break;
> }
> }
> --
> 2.1.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #221 from darkbasic --- Of course since 'radeonsi: Disable asynchronous DMA except for PIPE_BUFFER' the vast majority of crashes disappeared. -- 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/20141209/2bcf4a7a/attachment.html>
[PATCH] drm: fix a typo in a comment
Spotted while reviewing the DRM changes in Linux 3.18 for LinuxFR. Cc: Ville Syrjälä Signed--off-by: Martin Peres --- drivers/gpu/drm/drm_irq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c index 0e47df4..f5a5f18 100644 --- a/drivers/gpu/drm/drm_irq.c +++ b/drivers/gpu/drm/drm_irq.c @@ -166,7 +166,7 @@ static void vblank_disable_and_save(struct drm_device *dev, int crtc) spin_lock_irqsave(&dev->vblank_time_lock, irqflags); /* -* If the vblank interrupt was already disbled update the count +* If the vblank interrupt was already disabled update the count * and timestamp to maintain the appearance that the counter * has been ticking all along until this time. This makes the * count account for the entire time between drm_vblank_on() and -- 2.1.3
Long radeon stalls on recent kernels
On Tue, Dec 9, 2014 at 1:18 AM, Michel Dänzer wrote: > On 09.12.2014 09:24, Andy Lutomirski wrote: >> >> The relevant line from latencytop seems to be: >> >> 154 20441402 489139 radeon_fence_default_wait [radeon] >> fence_wait_timeout ttm_bo_wait [ttm] ttm_bo_move_accel_cleanup [ttm] >> radeon_move_blit.isra.12 [radeon] radeon_bo_move [radeon] >> ttm_bo_handle_move_mem [ttm] ttm_bo_evict [ttm] ttm_mem_evict_first >> [ttm] ttm_bo_mem_space [ttm] ttm_bo_validate [ttm] >> radeon_bo_fault_reserve_notify [radeon] > > Which process is this? Xorg > > Looks like CPU access to a BO in VRAM, but the BO is located outside of > the CPU visible area of VRAM, so it has to be moved into the CPU visible > area first. > > Which version of Mesa are you using? > mesa-dri-drivers-10.3.3-1.20141110.fc20.x86_64 I'm planning on upgrading to Fedora 21 fairly soon. --Andy > > -- > Earthling Michel Dänzer | http://www.amd.com > Libre software enthusiast | Mesa and X developer -- Andy Lutomirski AMA Capital Management, LLC
[Bug 89461] New: [Radeon - FirePro M7740] Dual screen fails with kernel version 3.17
https://bugzilla.kernel.org/show_bug.cgi?id=89461 Bug ID: 89461 Summary: [Radeon - FirePro M7740] Dual screen fails with kernel version 3.17 Product: Drivers Version: 2.5 Kernel Version: 3.17.x Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: glenn.larsen at gmail.com Regression: No Created attachment 160201 --> https://bugzilla.kernel.org/attachment.cgi?id=160201&action=edit dmesg with call trace Booting with a dual screen setup (using displayport and VGA), it fail during starting of Xorg. This happened from kernel 3.17. I have tested up to 3.17.6. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] drm: fix a word repetition in a comment
Spotted while reviewing the DRM changes in Linux 3.18 for LinuxFR. CC: Daniel Vetter Signed-off-by: Martin Peres --- drivers/gpu/drm/drm_crtc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index 4a44f89..90ad762 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -3454,7 +3454,7 @@ void drm_fb_release(struct drm_file *priv) /* * When the file gets released that means no one else can access the fb -* list any more, so no need to grab fpriv->fbs_lock. And we need to to +* list any more, so no need to grab fpriv->fbs_lock. And we need to * avoid upsetting lockdep since the universal cursor code adds a * framebuffer while holding mutex locks. * -- 2.1.3
[Bug 85647] Random radeonsi crashes with mesa 10.3.x
https://bugs.freedesktop.org/show_bug.cgi?id=85647 --- Comment #41 from Michel Dänzer --- (In reply to Hannu from comment #40) > Yes I know that 'radeonsi: Disable asynchronous DMA except for PIPE_BUFFER' > fixes the crash, but since the patch disables some of the functionality I > checked again with latest kernel. Note that I don't think the disabled functionality made a big difference anyway. -- 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/20141209/f65b67f3/attachment.html>
[Bug 85647] Random radeonsi crashes with mesa 10.3.x
https://bugs.freedesktop.org/show_bug.cgi?id=85647 --- Comment #40 from Hannu --- (In reply to agapito from comment #39) > (In reply to Hannu from comment #38) > > Created attachment 110558 [details] > > mesa 10.3.2-1 and linux 3.18.0 crash > > > > attached crash report from journalctl. Linux 3.18.0 and original debian mesa > > 10.3.2-1. I don't know if this adds anything new to report in attachment > > 108940 [details], there are some differences though. > > Try with mesa 10.3.4. > > http://www.mesa3d.org/relnotes/10.3.4.html Yes I know that 'radeonsi: Disable asynchronous DMA except for PIPE_BUFFER' fixes the crash, but since the patch disables some of the functionality I checked again with latest kernel. -- 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/20141209/bfd24557/attachment.html>
[Bug 85647] Random radeonsi crashes with mesa 10.3.x
https://bugs.freedesktop.org/show_bug.cgi?id=85647 --- Comment #39 from agapito --- (In reply to Hannu from comment #38) > Created attachment 110558 [details] > mesa 10.3.2-1 and linux 3.18.0 crash > > attached crash report from journalctl. Linux 3.18.0 and original debian mesa > 10.3.2-1. I don't know if this adds anything new to report in attachment > 108940 [details], there are some differences though. Try with mesa 10.3.4. http://www.mesa3d.org/relnotes/10.3.4.html -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141209/36267ac5/attachment-0001.html>
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #220 from agapito --- Since mesa 10.3.4 update i don't have this bug anymore on Archlinux. I've been "stable" for more than two weeks. http://www.mesa3d.org/relnotes/10.3.4.html -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141209/58e6c192/attachment.html>
