[Bug 79659] New: R9 270X lockup with unigine valley since radeonsi: enable ARB_sample_shading
4 21:59:33 ph4 kernel: [drm] ring test on 1 succeeded in 1 usecs Jun 4 21:59:33 ph4 kernel: [drm] ring test on 2 succeeded in 1 usecs Jun 4 21:59:33 ph4 kernel: [drm] ring test on 3 succeeded in 2 usecs Jun 4 21:59:33 ph4 kernel: [drm] ring test on 4 succeeded in 1 usecs Jun 4 21:59:33 ph4 kernel: [drm] ring test on 5 succeeded in 2 usecs Jun 4 21:59:33 ph4 kernel: [drm] UVD initialized successfully. Jun 4 21:59:43 ph4 kernel: radeon :01:00.0: ring 0 stalled for more than 1msec Jun 4 21:59:43 ph4 kernel: radeon :01:00.0: GPU lockup (waiting for 0x0002dc5a last fence id 0x0002dc3f on ring 0) Jun 4 21:59:43 ph4 kernel: [drm:r600_ib_test] *ERROR* radeon: fence wait failed (-35). Jun 4 21:59:43 ph4 kernel: [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on GFX ring (-35). Jun 4 21:59:43 ph4 kernel: radeon :01:00.0: ib ring test failed (-35). Jun 4 21:59:44 ph4 kernel: radeon :01:00.0: GPU softreset: 0x0048 Jun 4 21:59:44 ph4 kernel: radeon :01:00.0: GRBM_STATUS = 0xA0003028 Jun 4 21:59:44 ph4 kernel: radeon :01:00.0: GRBM_STATUS_SE0 = 0x0006 Jun 4 21:59:44 ph4 kernel: radeon :01:00.0: GRBM_STATUS_SE1 = 0x0006 Jun 4 21:59:44 ph4 kernel: radeon :01:00.0: SRBM_STATUS = 0x200400C0 Jun 4 21:59:44 ph4 kernel: radeon :01:00.0: SRBM_STATUS2 = 0x Jun 4 21:59:44 ph4 kernel: radeon :01:00.0: R_008674_CP_STALLED_STAT1 = 0x Jun 4 21:59:44 ph4 kernel: radeon :01:00.0: R_008678_CP_STALLED_STAT2 = 0x0001 Jun 4 21:59:44 ph4 kernel: radeon :01:00.0: R_00867C_CP_BUSY_STAT = 0x0042 Jun 4 21:59:44 ph4 kernel: radeon :01:00.0: R_008680_CP_STAT = 0x84010243 Jun 4 21:59:44 ph4 kernel: radeon :01:00.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 Jun 4 21:59:44 ph4 kernel: radeon :01:00.0: R_00D834_DMA_STATUS_REG = 0x44C83D57 Jun 4 21:59:44 ph4 kernel: radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x Jun 4 21:59:44 ph4 kernel: radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x Jun 4 21:59:44 ph4 kernel: SysRq : Emergency Sync Jun 4 21:59:44 ph4 kernel: Emergency Sync complete Jun 4 21:59:44 ph4 kernel: radeon :01:00.0: GRBM_SOFT_RESET=0xDDFF Jun 4 21:59:44 ph4 kernel: radeon :01:00.0: SRBM_SOFT_RESET=0x0100 Jun 4 21:59:44 ph4 kernel: radeon :01:00.0: GRBM_STATUS = 0x3028 Jun 4 21:59:44 ph4 kernel: radeon :01:00.0: GRBM_STATUS_SE0 = 0x0006 Jun 4 21:59:44 ph4 kernel: radeon :01:00.0: GRBM_STATUS_SE1 = 0x0006 Jun 4 21:59:44 ph4 kernel: radeon :01:00.0: SRBM_STATUS = 0x200400C0 Jun 4 21:59:44 ph4 kernel: radeon :01:00.0: SRBM_STATUS2 = 0x Jun 4 21:59:44 ph4 kernel: radeon :01:00.0: R_008674_CP_STALLED_STAT1 = 0x Jun 4 21:59:44 ph4 kernel: radeon :01:00.0: R_008678_CP_STALLED_STAT2 = 0x Jun 4 21:59:44 ph4 kernel: radeon :01:00.0: R_00867C_CP_BUSY_STAT = 0x Jun 4 21:59:44 ph4 kernel: radeon :01:00.0: R_008680_CP_STAT = 0x Jun 4 21:59:44 ph4 kernel: radeon :01:00.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 Jun 4 21:59:44 ph4 kernel: radeon :01:00.0: R_00D834_DMA_STATUS_REG = 0x44C83D57 Jun 4 21:59:44 ph4 kernel: radeon :01:00.0: GPU reset succeeded, trying to resume -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140604/ce5e55c0/attachment-0001.html>
[Bug 51381] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting, when disabled via vgaswitcheroo
https://bugzilla.kernel.org/show_bug.cgi?id=51381 --- Comment #15 from Teofilis Martisius --- Created attachment 138161 --> https://bugzilla.kernel.org/attachment.cgi?id=138161&action=edit Dmesg from 3.15rc7 from Debian/Experimental Asus K73TA laptop with AMD A6-3400M APU and Radeon 6550 GPU -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 51381] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting, when disabled via vgaswitcheroo
https://bugzilla.kernel.org/show_bug.cgi?id=51381 --- Comment #14 from Teofilis Martisius --- Hi, Thank you for very quick response. I have just tried v3.15rc7 from Debian Experimental, it still has this same problem. I have attached an excerpt from dmesg at the end of this message. I'll attach a full dmesg log as well. I have tried same kernel with radeon.runpm=0, and it works correctly. I can run glxgears on both my primary and my secondary GPU with "xrandr --setprovideroffloadsink xx yy" and "DRI_PRIME=1 glxgears". Both work correctly. So disabling power management works as a workaround. However, it's just a workaround, and it would be interesting to get the underlying issue fixed. I'll try 3.15rc8 next, see if that has any improvements. P.S. My current kernel boot-time options are: quiet radeon.audio=0 modeset=1 radeon.dpm=1 radeon.no_wb=1 radeon.runpm=0 I'm running Debian/Sid. Could it be something broken in userspace interfering? Sincerely, Teofilis Martisius == [ 55.886107] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting [ 55.886234] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing CE56 (len 62, WS 0, PS 0) @ 0xCE72 [ 55.889662] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing BB62 (len 1036, WS 4, PS 0) @ 0xBC5F [ 55.892979] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing BAF8 (len 76, WS 0, PS 8) @ 0xBB00 [ 55.896345] [drm:radeon_pm_resume_dpm] *ERROR* radeon: dpm resume failed [ 57.418996] radeon :01:00.0: Wait for MC idle timedout ! [ 57.609356] radeon :01:00.0: Wait for MC idle timedout ! [ 57.628060] [drm] PCIE GART of 1024M enabled (table at 0x00273000). [ 57.628181] radeon :01:00.0: WB enabled [ 57.628189] radeon :01:00.0: fence driver on ring 0 use gpu addr 0x4c00 and cpu addr 0x88014876ac00 [ 57.628194] radeon :01:00.0: fence driver on ring 3 use gpu addr 0x4c0c and cpu addr 0x88014876ac0c [ 57.637229] radeon :01:00.0: fence driver on ring 5 use gpu addr 0x00072118 and cpu addr 0xc90011cb2118 [ 57.844594] [drm:r600_ring_test] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0x) [ 57.844724] [drm:evergreen_resume] *ERROR* evergreen startup failed on resume [ 57.847954] [drm:radeon_pm_resume_dpm] *ERROR* radeon: dpm resume failed -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 3.4 184/214] drm: Pad drm_mode_get_connector to 64-bit boundary
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Chris Wilson
commit bc5bd37ce48c66e9192ad2e7231e9678880f6f8e upstream.
Pavel Roskin reported that DRM_IOCTL_MODE_GETCONNECTOR was overwritting
the 4 bytes beyond the end of its structure with a 32-bit userspace
running on a 64-bit kernel. This is due to the padding gcc inserts as
the drm_mode_get_connector struct includes a u64 and its size is not a
natural multiple of u64s.
64-bit kernel:
sizeof(drm_mode_get_connector)=80, alignof=8
sizeof(drm_mode_get_encoder)=20, alignof=4
sizeof(drm_mode_modeinfo)=68, alignof=4
32-bit userspace:
sizeof(drm_mode_get_connector)=76, alignof=4
sizeof(drm_mode_get_encoder)=20, alignof=4
sizeof(drm_mode_modeinfo)=68, alignof=4
Fortuituously we can insert explicit padding to the tail of our
structures without breaking ABI.
Reported-by: Pavel Roskin
Signed-off-by: Chris Wilson
Cc: Dave Airlie
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Dave Airlie
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings
Cc: Weng Meiling
Signed-off-by: Greg Kroah-Hartman
---
include/drm/drm_mode.h |2 ++
1 file changed, 2 insertions(+)
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -223,6 +223,8 @@ struct drm_mode_get_connector {
__u32 connection;
__u32 mm_width, mm_height; /**< HxW in millimeters */
__u32 subpixel;
+
+ __u32 pad;
};
#define DRM_MODE_PROP_PENDING (1<<0)
[Bug 51381] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting, when disabled via vgaswitcheroo
https://bugzilla.kernel.org/show_bug.cgi?id=51381 --- Comment #13 from Alex Deucher --- There have been a lot of PX fixes in 3.15. Can you try 3.15? Additionally, you can disable the PX runtime pm support by appending radeon.runpm=0 on the kernel command line in grub. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 51381] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting, when disabled via vgaswitcheroo
https://bugzilla.kernel.org/show_bug.cgi?id=51381 Teofilis Martisius changed: What|Removed |Added CC||Teofilis.Martisius at gmail.co ||m --- Comment #12 from Teofilis Martisius --- Hello, I'm not sure if the problem I have is the same as reported in the original bug report on 2012-12-07, but I have a problem very similar to one described by newgarry on 2014-05-04. I have an Asus K73TA laptop with AMD A6-3400M APU and Radeon 6550 GPU. I get foloowing errors on boot with Kernels version 3.13 and above: [ 53.720848] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting [ 53.720975] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing CE56 (len 62, WS 0, PS 0) @ 0xCE72 [ 53.721107] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing BB62 (len 1036, WS 4, PS 0) @ 0xBC5F [ 53.721240] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing BAF8 (len 76, WS 0, PS 8) @ 0xBB00 [ 55.775951] [drm:r600_ring_test] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0x) [ 55.776083] [drm:evergreen_resume] *ERROR* evergreen startup failed on resume [ 55.776364] [drm:radeon_pm_resume_dpm] *ERROR* radeon: dpm resume failed Initially I thought this is Debian specific so I reported it on Debian BTS, it has more details here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737684 I bisected kernel versions between 3.12 and 3.13 and I determined that this issue was introduced in the following git commit: commit 10ebc0bc09344ab6310309169efc73dfe6c23d72 Author: Dave Airlie Date: Mon Sep 17 14:40:31 2012 +1000 drm/radeon: add runtime PM support (v2) This hooks radeon up to the runtime PM system to enable dynamic power management for secondary GPUs in switchable and powerxpress laptops. v2: agd5f: clean up, add module parameter Signed-off-by: Dave Airlie Signed-off-by: Alex Deucher Newgarry, can you please try kernel v3.12 and see if it works correctly for you? Because of this issue I cannot upgrade my kernel to anything above 3.12. I spent a week bisecting the kernel, so I would really appreciate someone looking into this. I tried reviewing the changes introduced in this commit, but I know too little about radon drivers to be able to understand the impact they had. If you need me to do any additional testing or provide you with extra information, please don't hesitate to contact me, I'll do what I can. Sincerely, Teofilis Martisius -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] gpu: drm: msm: Replace type of paddr to uint32_t.
On Wed, Jun 4, 2014 at 6:54 AM, Matwey V. Kornilov wrote:
> From e7147352639fd8f92b1cc85cff9bc5046c7a2130 Mon Sep 17 00:00:00 2001
> From: "Matwey V. Kornilov"
> Date: Mon, 2 Jun 2014 20:17:29 +0400
> Subject: [PATCH] Replace type of paddr to uint32_t.
>
> This patch helps to avoid the following build issue:
>
> drivers/gpu/drm/msm/msm_fbdev.c:108:2: error: passing argument 3 of
> 'msm_gem_get_iova_locked' from incompatible pointer type [-Werror]
> msm_gem_get_iova_locked(fbdev->bo, 0, &paddr);
> ^
> In file included from drivers/gpu/drm/msm/msm_fbdev.c:18:0:
> drivers/gpu/drm/msm/msm_drv.h:153:5: note: expected 'uint32_t *' but
> argument is of type 'dma_addr_t *'
> int msm_gem_get_iova_locked(struct drm_gem_object *obj, int id,
> ^
>
> Signed-off-by: Matwey V. Kornilov
Reviewed-by: Rob Clark
> ---
> drivers/gpu/drm/msm/msm_fbdev.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_fbdev.c
> b/drivers/gpu/drm/msm/msm_fbdev.c
> index a752ab8..5107fc4 100644
> --- a/drivers/gpu/drm/msm/msm_fbdev.c
> +++ b/drivers/gpu/drm/msm/msm_fbdev.c
> @@ -59,7 +59,7 @@ static int msm_fbdev_create(struct drm_fb_helper *helper,
> struct drm_framebuffer *fb = NULL;
> struct fb_info *fbi = NULL;
> struct drm_mode_fb_cmd2 mode_cmd = {0};
> - dma_addr_t paddr;
> + uint32_t paddr;
> int ret, size;
>
> sizes->surface_bpp = 32;
> --
> 1.9.3
>
> --
> 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 79649] [PATCH RFC] r300/compiler: recursive look for RC_OPCODE_S**
https://bugs.freedesktop.org/show_bug.cgi?id=79649 David Heidelberger (okias) changed: What|Removed |Added CC||david.heidelberger at ixit.cz, ||maraeo at gmail.com, ||tstellar at gmail.com Keywords||patch -- 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/20140604/c6edb1f7/attachment.html>
[Bug 79649] [PATCH RFC] r300/compiler: recursive look for RC_OPCODE_S**
https://bugs.freedesktop.org/show_bug.cgi?id=79649 --- Comment #4 from David Heidelberger (okias) --- Created attachment 100419 --> https://bugs.freedesktop.org/attachment.cgi?id=100419&action=edit discard-statement-in-for-loop-AFTER.txt All txt are with RADEON_DEBUG=fp -- 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/20140604/a134c240/attachment.html>
[Bug 79649] [PATCH RFC] r300/compiler: recursive look for RC_OPCODE_S**
https://bugs.freedesktop.org/show_bug.cgi?id=79649 --- Comment #3 from Grigori Goronzy --- I think the right place for this is mesa-dev...? -- 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/20140604/1dfc48e7/attachment.html>
[Bug 79649] [PATCH RFC] r300/compiler: recursive look for RC_OPCODE_S**
https://bugs.freedesktop.org/show_bug.cgi?id=79649 --- Comment #2 from David Heidelberger (okias) --- Created attachment 100418 --> https://bugs.freedesktop.org/attachment.cgi?id=100418&action=edit ~/while-loop-with-continue-AFTER.txt -- 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/20140604/62c0a701/attachment.html>
[Bug 79649] [PATCH RFC] r300/compiler: recursive look for RC_OPCODE_S**
https://bugs.freedesktop.org/show_bug.cgi?id=79649 --- Comment #1 from David Heidelberger (okias) --- Created attachment 100417 --> https://bugs.freedesktop.org/attachment.cgi?id=100417&action=edit for-loop-with-continue-AFTER.txt -- 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/20140604/1625630e/attachment.html>
[Bug 79649] New: [PATCH RFC] r300/compiler: recursive look for RC_OPCODE_S**
https://bugs.freedesktop.org/show_bug.cgi?id=79649 Priority: medium Bug ID: 79649 Assignee: dri-devel at lists.freedesktop.org Summary: [PATCH RFC] r300/compiler: recursive look for RC_OPCODE_S** Severity: normal Classification: Unclassified OS: All Reporter: david.heidelberger at ixit.cz Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/r300 Product: Mesa Created attachment 100416 --> https://bugs.freedesktop.org/attachment.cgi?id=100416&action=edit 0001-r300-compiler-recursive-look-for-RC_OPCODE_S.patch Get rid of error "Failed to build loop info" by fixing failure in cases like 4: SGE temp[2].x, temp[0]., const[0].; 5: CMP temp[1].x, -temp[2]., const[0]., temp[1].; 6: IF temp[1].; On RS690 - fixes piglit glean "do-loop with continue and break" - changes error from Failed to build loop info -> Not a native swizzle: 0e89 r300_fragprog_emit.c::begin_tex(): Too many texture indirections for "discard statement in for loop" - hide Failed to build loop info for "precision log2", "while-loop with continue", "for-loop with continue" and return "1 1 1 1" insted of "0 0 0 1" -- 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/20140604/fe59fcbd/attachment.html>
[PATCH v3 13/15] ARM: dts: exynos5: add system register support
On Mon, Jun 2, 2014 at 10:52 AM, YoungJun Cho wrote:
> This patch adds sysreg device node, and sysreg property
> to fimd device node which is required to use I80 interface.
Same here. The system register nodes have been added to exynos5250 and
exynos5420 by the patch:
dfbbdbf ARM: dts: Add sysreg sytem controller node to exynos5250 and exynos5420
May be, you may want to move those two nodes to this common file (exynos5.dtsi).
>
> Signed-off-by: YoungJun Cho
> Acked-by: Inki Dae
> Acked-by: Kyungmin Park
> ---
> arch/arm/boot/dts/exynos5.dtsi |6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
> index 79d0608..95ee496 100644
> --- a/arch/arm/boot/dts/exynos5.dtsi
> +++ b/arch/arm/boot/dts/exynos5.dtsi
> @@ -81,12 +81,18 @@
> status = "disabled";
> };
>
> + sys_reg: syscon at 1005 {
> + compatible = "samsung,exynos5-sysreg", "syscon";
> + reg = <0x1005 0x500>;
> + };
> +
> fimd at 1440 {
> compatible = "samsung,exynos5250-fimd";
> interrupt-parent = <&combiner>;
> reg = <0x1440 0x4>;
> interrupt-names = "fifo", "vsync", "lcd_sys";
> interrupts = <18 4>, <18 5>, <18 6>;
> + samsung,sysreg = <&sys_reg>;
> status = "disabled";
> };
>
> --
> 1.7.9.5
>
> --
> 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
--
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
[PATCH v3 03/15] ARM: dts: sysreg: add exynos5 compatible to DT bindings
Hi, On Mon, Jun 2, 2014 at 10:52 AM, YoungJun Cho wrote: > This patch adds relevant to exynos5 compatible for exynos5 SoCs. This change is not required. Please check the latest 'for-next' branch of linux-samsung tree. Recently a patch "dfbbdbf ARM: dts: Add sysreg sytem controller node to exynos5250 and exynos5420" has already updated this binding information. > > Signed-off-by: YoungJun Cho > Acked-by: Inki Dae > Acked-by: Kyungmin Park > --- > .../devicetree/bindings/arm/samsung/sysreg.txt |1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/arm/samsung/sysreg.txt > b/Documentation/devicetree/bindings/arm/samsung/sysreg.txt > index 0ab3251..fd71581 100644 > --- a/Documentation/devicetree/bindings/arm/samsung/sysreg.txt > +++ b/Documentation/devicetree/bindings/arm/samsung/sysreg.txt > @@ -3,6 +3,7 @@ SAMSUNG S5P/Exynos SoC series System Registers (SYSREG) > Properties: > - compatible : should contain "samsung,-sysreg", "syscon"; > For Exynos4 SoC series it should be "samsung,exynos4-sysreg", "syscon"; > + For Exynos5 SoC series it should be "samsung,exynos5-sysreg", "syscon"; > - reg : offset and length of the register set. > > Example: > -- > 1.7.9.5 > > -- > 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 -- Best Regards Vivek Gautam Samsung R&D Institute, Bangalore India
[PATCH 1/2] drm: convert crtc and connection_mutex to ww_mutex (v4)
On Wed, Jun 04, 2014 at 10:27:25AM -0400, Rob Clark wrote:
> For atomic, it will be quite necessary to not need to care so much
> about locking order. And 'state' gives us a convenient place to stash a
> ww_ctx for any sort of update that needs to grab multiple crtc locks.
>
> Because we will want to eventually make locking even more fine grained
> (giving locks to planes, connectors, etc), split out drm_modeset_lock
> and drm_modeset_acquire_ctx to track acquired locks.
>
> Atomic will use this to keep track of which locks have been acquired
> in a transaction.
>
> v1: original
> v2: remove a few things not needed until atomic, for now
> v3: update for v3 of connection_mutex patch..
> v4: squash in docbook
>
> Signed-off-by: Rob Clark
Ok, only checked the kerneldoc now and found a few nitpicks. With those
fixed and presuming no bugs added to the code compared to last version
this is Reviewed-by: Daniel Vetter
> ---
> Documentation/DocBook/drm.tmpl| 6 +
> drivers/gpu/drm/Makefile | 3 +-
> drivers/gpu/drm/drm_crtc.c| 85 +---
> drivers/gpu/drm/drm_crtc_helper.c | 3 +-
> drivers/gpu/drm/drm_fb_helper.c | 4 +
> drivers/gpu/drm/drm_modeset_lock.c| 247
> ++
> drivers/gpu/drm/drm_plane_helper.c| 2 +-
> drivers/gpu/drm/i915/intel_crt.c | 5 +-
> drivers/gpu/drm/i915/intel_display.c | 56 +---
> drivers/gpu/drm/i915/intel_dp.c | 14 +-
> drivers/gpu/drm/i915/intel_drv.h | 6 +-
> drivers/gpu/drm/i915/intel_opregion.c | 4 +-
> drivers/gpu/drm/i915/intel_overlay.c | 4 +-
> drivers/gpu/drm/i915/intel_panel.c| 8 +-
> drivers/gpu/drm/i915/intel_sprite.c | 2 +-
> drivers/gpu/drm/i915/intel_tv.c | 5 +-
> drivers/gpu/drm/omapdrm/omap_crtc.c | 10 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 8 +-
> include/drm/drmP.h| 5 -
> include/drm/drm_crtc.h| 15 ++-
> include/drm/drm_modeset_lock.h| 123 +
> 21 files changed, 528 insertions(+), 87 deletions(-)
> create mode 100644 drivers/gpu/drm/drm_modeset_lock.c
> create mode 100644 include/drm/drm_modeset_lock.h
>
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index 00f1c25..efef637 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -1791,6 +1791,12 @@ void intel_crt_init(struct drm_device *dev)
>KMS API Functions
> !Edrivers/gpu/drm/drm_crtc.c
>
> +
> + KMS Locking
> +!Pdrivers/gpu/drm/drm_modeset_lock.c kms locking
> +!Iinclude/drm/drm_modeset_lock.h
> +!Edrivers/gpu/drm/drm_modeset_lock.c
> +
>
>
>
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 863db84..dd2ba42 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -13,7 +13,8 @@ drm-y := drm_auth.o drm_buffer.o drm_bufs.o
> drm_cache.o \
> drm_crtc.o drm_modes.o drm_edid.o \
> drm_info.o drm_debugfs.o drm_encoder_slave.o \
> drm_trace_points.o drm_global.o drm_prime.o \
> - drm_rect.o drm_vma_manager.o drm_flip_work.o
> + drm_rect.o drm_vma_manager.o drm_flip_work.o \
> + drm_modeset_lock.o
>
> drm-$(CONFIG_COMPAT) += drm_ioc32.o
> drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index f3b98d4..43735f3 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -37,6 +37,7 @@
> #include
> #include
> #include
> +#include
>
> #include "drm_crtc_internal.h"
>
> @@ -50,14 +51,42 @@
> */
> void drm_modeset_lock_all(struct drm_device *dev)
> {
> - struct drm_crtc *crtc;
> + struct drm_mode_config *config = &dev->mode_config;
> + struct drm_modeset_acquire_ctx *ctx;
> + int ret;
>
> - mutex_lock(&dev->mode_config.mutex);
> + ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
> + if (WARN_ON(!ctx))
> + return;
>
> - mutex_lock(&dev->mode_config.connection_mutex);
> + mutex_lock(&config->mutex);
>
> - list_for_each_entry(crtc, &dev->mode_config.crtc_list, head)
> - mutex_lock_nest_lock(&crtc->mutex, &dev->mode_config.mutex);
> + drm_modeset_acquire_init(ctx, 0);
> +
> +retry:
> + ret = drm_modeset_lock(&config->connection_mutex, ctx);
> + if (ret)
> + goto fail;
> + ret = drm_modeset_lock_all_crtcs(dev, ctx);
> + if (ret)
> + goto fail;
> +
> + WARN_ON(config->acquire_ctx);
> +
> + /* now we hold the locks, so now that it is safe, stash the
> + * ctx for drm_modeset_unlock_all():
> + */
> + config->acquire_ctx = ctx;
> +
> + drm_warn_on_modeset_not_all_locked(dev);
> +
> + return;
> +
> +fail:
> + if (ret == -EDEADLK) {
> + drm_modeset_backoff(ctx);
> + goto retry;
>
[PATCH] drm/dp: add a hw mutex around the transfer functions.
From: Dave Airlie
This should avoid races between connector probing and HPD
irqs in the future, currently mode_config.mutex blocks this
possibility.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_dp_helper.c | 15 +++
drivers/gpu/drm/i915/intel_dp.c | 1 +
drivers/gpu/drm/radeon/atombios_dp.c | 2 ++
drivers/gpu/drm/tegra/dpaux.c| 1 +
include/drm/drm_dp_helper.h | 3 ++-
5 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 494219c..cb687f4 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -382,7 +382,10 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8
request,
* transactions.
*/
for (retry = 0; retry < 7; retry++) {
+
+ mutex_lock(&aux->hw_mutex);
err = aux->transfer(aux, &msg);
+ mutex_unlock(&aux->hw_mutex);
if (err < 0) {
if (err == -EBUSY)
continue;
@@ -596,7 +599,9 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct
drm_dp_aux_msg *msg)
* before giving up the AUX transaction.
*/
for (retry = 0; retry < 7; retry++) {
+ mutex_lock(&aux->hw_mutex);
err = aux->transfer(aux, msg);
+ mutex_unlock(&aux->hw_mutex);
if (err < 0) {
if (err == -EBUSY)
continue;
@@ -761,3 +766,13 @@ void drm_dp_aux_unregister_i2c_bus(struct drm_dp_aux *aux)
i2c_del_adapter(&aux->ddc);
}
EXPORT_SYMBOL(drm_dp_aux_unregister_i2c_bus);
+
+/**
+ * drm_dp_aux_init() - init a DP aux internal structure.
+ * @aux: DisplayPort AUX channel
+ */
+void drm_dp_aux_init(struct drm_dp_aux *aux)
+{
+ mutex_init(&aux->hw_mutex);
+}
+EXPORT_SYMBOL(drm_dp_aux_init);
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index c4d8839..aa99dcb 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -698,6 +698,7 @@ intel_dp_aux_init(struct intel_dp *intel_dp, struct
intel_connector *connector)
intel_dp->aux.name = name;
intel_dp->aux.dev = dev->dev;
intel_dp->aux.transfer = intel_dp_aux_transfer;
+ drm_dp_aux_init(&intel_dp->aux);
DRM_DEBUG_KMS("registering %s bus for %s\n", name,
connector->base.kdev->kobj.name);
diff --git a/drivers/gpu/drm/radeon/atombios_dp.c
b/drivers/gpu/drm/radeon/atombios_dp.c
index 225f6c6..12d8784 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -222,6 +222,8 @@ void radeon_dp_aux_init(struct radeon_connector
*radeon_connector)
radeon_connector->ddc_bus->rec.hpd = radeon_connector->hpd.hpd;
radeon_connector->ddc_bus->aux.dev = radeon_connector->base.kdev;
radeon_connector->ddc_bus->aux.transfer = radeon_dp_aux_transfer;
+
+ drm_dp_aux_init(&radeon_connector->ddc_bus->aux);
ret = drm_dp_aux_register_i2c_bus(&radeon_connector->ddc_bus->aux);
if (!ret)
radeon_connector->ddc_bus->has_aux = true;
diff --git a/drivers/gpu/drm/tegra/dpaux.c b/drivers/gpu/drm/tegra/dpaux.c
index 005c19b..98cd70b 100644
--- a/drivers/gpu/drm/tegra/dpaux.c
+++ b/drivers/gpu/drm/tegra/dpaux.c
@@ -331,6 +331,7 @@ static int tegra_dpaux_probe(struct platform_device *pdev)
dpaux->aux.transfer = tegra_dpaux_transfer;
dpaux->aux.dev = &pdev->dev;
+ drm_dp_aux_init(&dpaux->aux);
err = drm_dp_aux_register_i2c_bus(&dpaux->aux);
if (err < 0)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 488b416..09eee36 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -546,7 +546,7 @@ struct drm_dp_aux {
const char *name;
struct i2c_adapter ddc;
struct device *dev;
-
+ struct mutex hw_mutex;
ssize_t (*transfer)(struct drm_dp_aux *aux,
struct drm_dp_aux_msg *msg);
};
@@ -607,5 +607,6 @@ int drm_dp_link_configure(struct drm_dp_aux *aux, struct
drm_dp_link *link);
int drm_dp_aux_register_i2c_bus(struct drm_dp_aux *aux);
void drm_dp_aux_unregister_i2c_bus(struct drm_dp_aux *aux);
+void drm_dp_aux_init(struct drm_dp_aux *aux);
#endif /* _DRM_DP_HELPER_H_ */
--
1.9.3
[PATCH 1/3] drm/radeon: stop poisoning the GART TLB
Am 04.06.2014 15:46, schrieb Alex Deucher: > On Wed, Jun 4, 2014 at 9:29 AM, Christian K?nig > wrote: >> From: Christian K?nig >> >> When we set the valid bit on invalid GART entries they are >> loaded into the TLB when an adjacent entry is loaded. This >> poisons the TLB with invalid entries which are sometimes >> not correctly removed on TLB flush. >> >> For stable inclusion the patch probably needs to be modified a bit. >> >> Signed-off-by: Christian K?nig >> Cc: stable at vger.kernel.org > Series is: > Reviewed-by: Alex Deucher > > stable cc on patch 2 or 3 as well? I suppose we'd need to modify the > patches anyway so that they would apply on older kernels anyway. No, the second patch is just an improvement of removing unnecessary checks and I think using the CPDMA on stable kernels is maybe still a good idea. Christian > > Alex > >> --- >> drivers/gpu/drm/radeon/rs600.c | 5 - >> 1 file changed, 4 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/radeon/rs600.c b/drivers/gpu/drm/radeon/rs600.c >> index 0a8be63..e0465b2 100644 >> --- a/drivers/gpu/drm/radeon/rs600.c >> +++ b/drivers/gpu/drm/radeon/rs600.c >> @@ -634,7 +634,10 @@ int rs600_gart_set_page(struct radeon_device *rdev, int >> i, uint64_t addr) >> return -EINVAL; >> } >> addr = addr & 0xF000ULL; >> - addr |= R600_PTE_GART; >> + if (addr == rdev->dummy_page.addr) >> + addr |= R600_PTE_SYSTEM | R600_PTE_SNOOPED; >> + else >> + addr |= R600_PTE_GART; >> writeq(addr, ptr + (i * 8)); >> return 0; >> } >> -- >> 1.9.1 >>
[Bug 79520] mpv 0.3.10-1 shows no video after mesa and ati-dri update to version 10.2.0rc5-1
https://bugs.freedesktop.org/show_bug.cgi?id=79520 --- Comment #15 from Christian K?nig --- Ok that sounds like you updated the OpenGL packages, but not VDPAU right? Well in this case the reason it doesn't work any more is that OpenGL advertises OpenGL/VDPAU interop, but the VDPAU driver actually isn't new enough end rejects the export request. Try the --hwdec=no option on mpv. -- 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/20140604/6eeda9c1/attachment.html>
[PATCH] drm/i915: rework digital port IRQ handling
From: Dave Airlie
The digital ports from Ironlake and up have the ability to distinguish
between long and short HPD pulses. Displayport 1.1 only uses the short
form to request link retraining usually, so we haven't really needed
support for it until now.
However with DP 1.2 MST we need to handle the short irqs on their
own outside the modesetting locking the long hpd's involve. This
patch adds the framework to distinguish between short/long to the
current code base, to lay the basis for future DP 1.2 MST work.
This should mean we get better bisectability in case of regression
due to the new irq handling.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/i915_drv.h | 5 ++
drivers/gpu/drm/i915/i915_irq.c | 138 ---
drivers/gpu/drm/i915/intel_ddi.c | 3 +
drivers/gpu/drm/i915/intel_dp.c | 22 +++
drivers/gpu/drm/i915/intel_drv.h | 2 +
5 files changed, 162 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8f68678..5fd5bf3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1551,6 +1551,11 @@ struct drm_i915_private {
struct i915_runtime_pm pm;
+ struct intel_digital_port *hpd_irq_port[I915_MAX_PORTS];
+ u32 long_hpd_port_mask;
+ u32 short_hpd_port_mask;
+ struct work_struct dig_port_work;
+
/* Old dri1 support infrastructure, beware the dragons ya fools entering
* here! */
struct i915_dri1_state dri1;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index cbf31cb..1817eaa 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1096,6 +1096,53 @@ static bool intel_hpd_irq_event(struct drm_device *dev,
return true;
}
+static void i915_digport_work_func(struct work_struct *work)
+{
+ struct drm_i915_private *dev_priv =
+ container_of(work, struct drm_i915_private, dig_port_work);
+ unsigned long irqflags;
+ u32 long_port_mask, short_port_mask;
+ struct intel_digital_port *intel_dig_port;
+ int i, ret;
+ u32 old_bits = 0;
+
+ spin_lock_irqsave(&dev_priv->irq_lock, irqflags);
+ long_port_mask = dev_priv->long_hpd_port_mask;
+ dev_priv->long_hpd_port_mask = 0;
+ short_port_mask = dev_priv->short_hpd_port_mask;
+ dev_priv->short_hpd_port_mask = 0;
+ spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags);
+
+ for (i = 0; i < I915_MAX_PORTS; i++) {
+ bool valid = false;
+ bool long_hpd = false;
+ intel_dig_port = dev_priv->hpd_irq_port[i];
+ if (!intel_dig_port || !intel_dig_port->hpd_pulse)
+ continue;
+
+ if (long_port_mask & (1 << i)) {
+ valid = true;
+ long_hpd = true;
+ } else if (short_port_mask & (1 << i))
+ valid = true;
+
+ if (valid) {
+ ret = intel_dig_port->hpd_pulse(intel_dig_port,
long_hpd);
+ if (ret == true) {
+ /* if we get true fallback to old school hpd */
+ old_bits |= (1 << intel_dig_port->base.hpd_pin);
+ }
+ }
+ }
+
+ if (old_bits) {
+ spin_lock_irqsave(&dev_priv->irq_lock, irqflags);
+ dev_priv->hpd_event_bits |= old_bits;
+ spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags);
+ schedule_work(&dev_priv->hotplug_work);
+ }
+}
+
/*
* Handle hotplug events outside the interrupt handler proper.
*/
@@ -1520,23 +1567,82 @@ static irqreturn_t gen8_gt_irq_handler(struct
drm_device *dev,
#define HPD_STORM_DETECT_PERIOD 1000
#define HPD_STORM_THRESHOLD 5
+static int port_to_hotplug_shift(enum port port)
+{
+ switch (port) {
+ case PORT_A:
+ case PORT_E:
+ default:
+ return -1;
+ case PORT_B:
+ return 0;
+ case PORT_C:
+ return 8;
+ case PORT_D:
+ return 16;
+ }
+}
+
+static inline enum port get_port_from_pin(enum hpd_pin pin)
+{
+ switch (pin) {
+ case HPD_PORT_B:
+ return PORT_B;
+ case HPD_PORT_C:
+ return PORT_C;
+ case HPD_PORT_D:
+ return PORT_D;
+ default:
+ return PORT_A; /* no hpd */
+ }
+}
+
static inline void intel_hpd_irq_handler(struct drm_device *dev,
u32 hotplug_trigger,
+u32 dig_hotplug_reg,
const u32 *hpd)
{
struct drm_i915_private *dev_priv = dev->dev_private;
int i;
+ enum port port;
bool storm_detected = false;
+ bool queue_dig = false, queue_hp = false;
+
[PATCH 3/3] drm/radeon: use the SDMA on for buffer moves on CIK again
From: Christian K?nig
The underlying reason for the crashes seems to be fixed now.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_asic.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
b/drivers/gpu/drm/radeon/radeon_asic.c
index 34ea53d..34b9aa9 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -2029,8 +2029,8 @@ static struct radeon_asic ci_asic = {
.blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
.dma = &cik_copy_dma,
.dma_ring_index = R600_RING_TYPE_DMA_INDEX,
- .copy = &cik_copy_cpdma,
- .copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
+ .copy = &cik_copy_dma,
+ .copy_ring_index = R600_RING_TYPE_DMA_INDEX,
},
.surface = {
.set_reg = r600_set_surface_reg,
--
1.9.1
[PATCH 2/3] drm/radeon: remove range check from *_gart_set_page
From: Christian K?nig
We never check the return value anyway and if the
index isn't valid would crash way before calling
the functions.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/r100.c| 8 ++--
drivers/gpu/drm/radeon/r300.c| 7 ++-
drivers/gpu/drm/radeon/radeon.h | 3 ++-
drivers/gpu/drm/radeon/radeon_asic.h | 12
drivers/gpu/drm/radeon/rs400.c | 7 +--
drivers/gpu/drm/radeon/rs600.c | 6 +-
6 files changed, 16 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index ad99813..1544efc 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -682,15 +682,11 @@ void r100_pci_gart_disable(struct radeon_device *rdev)
WREG32(RADEON_AIC_HI_ADDR, 0);
}
-int r100_pci_gart_set_page(struct radeon_device *rdev, int i, uint64_t addr)
+void r100_pci_gart_set_page(struct radeon_device *rdev, unsigned i,
+ uint64_t addr)
{
u32 *gtt = rdev->gart.ptr;
-
- if (i < 0 || i > rdev->gart.num_gpu_pages) {
- return -EINVAL;
- }
gtt[i] = cpu_to_le32(lower_32_bits(addr));
- return 0;
}
void r100_pci_gart_fini(struct radeon_device *rdev)
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 206caf9..3c21d77 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -72,13 +72,11 @@ void rv370_pcie_gart_tlb_flush(struct radeon_device *rdev)
#define R300_PTE_WRITEABLE (1 << 2)
#define R300_PTE_READABLE (1 << 3)
-int rv370_pcie_gart_set_page(struct radeon_device *rdev, int i, uint64_t addr)
+void rv370_pcie_gart_set_page(struct radeon_device *rdev, unsigned i,
+ uint64_t addr)
{
void __iomem *ptr = rdev->gart.ptr;
- if (i < 0 || i > rdev->gart.num_gpu_pages) {
- return -EINVAL;
- }
addr = (lower_32_bits(addr) >> 8) |
((upper_32_bits(addr) & 0xff) << 24) |
R300_PTE_WRITEABLE | R300_PTE_READABLE;
@@ -86,7 +84,6 @@ int rv370_pcie_gart_set_page(struct radeon_device *rdev, int
i, uint64_t addr)
* on powerpc without HW swappers, it'll get swapped on way
* into VRAM - so no need for cpu_to_le32 on VRAM tables */
writel(addr, ((void __iomem *)ptr) + (i * 4));
- return 0;
}
int rv370_pcie_gart_init(struct radeon_device *rdev)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 0661a77..c08987c 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1778,7 +1778,8 @@ struct radeon_asic {
/* gart */
struct {
void (*tlb_flush)(struct radeon_device *rdev);
- int (*set_page)(struct radeon_device *rdev, int i, uint64_t
addr);
+ void (*set_page)(struct radeon_device *rdev, unsigned i,
+uint64_t addr);
} gart;
struct {
int (*init)(struct radeon_device *rdev);
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h
b/drivers/gpu/drm/radeon/radeon_asic.h
index 0eab015..01e7c0a 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -67,7 +67,8 @@ bool r100_gpu_is_lockup(struct radeon_device *rdev, struct
radeon_ring *cp);
int r100_asic_reset(struct radeon_device *rdev);
u32 r100_get_vblank_counter(struct radeon_device *rdev, int crtc);
void r100_pci_gart_tlb_flush(struct radeon_device *rdev);
-int r100_pci_gart_set_page(struct radeon_device *rdev, int i, uint64_t addr);
+void r100_pci_gart_set_page(struct radeon_device *rdev, unsigned i,
+ uint64_t addr);
void r100_ring_start(struct radeon_device *rdev, struct radeon_ring *ring);
int r100_irq_set(struct radeon_device *rdev);
int r100_irq_process(struct radeon_device *rdev);
@@ -171,7 +172,8 @@ extern void r300_fence_ring_emit(struct radeon_device *rdev,
struct radeon_fence *fence);
extern int r300_cs_parse(struct radeon_cs_parser *p);
extern void rv370_pcie_gart_tlb_flush(struct radeon_device *rdev);
-extern int rv370_pcie_gart_set_page(struct radeon_device *rdev, int i,
uint64_t addr);
+extern void rv370_pcie_gart_set_page(struct radeon_device *rdev, unsigned i,
+uint64_t addr);
extern void rv370_set_pcie_lanes(struct radeon_device *rdev, int lanes);
extern int rv370_get_pcie_lanes(struct radeon_device *rdev);
extern void r300_set_reg_safe(struct radeon_device *rdev);
@@ -206,7 +208,8 @@ extern void rs400_fini(struct radeon_device *rdev);
extern int rs400_suspend(struct radeon_device *rdev);
extern int rs400_resume(struct radeon_device *rdev);
void rs400_gart_tlb_flush(struct radeon_device *rdev);
-int rs400_gart_set_page(struct radeon_device *rdev, int i, uint64_t addr);
+void rs400_gart_set_page(struct radeon_device *rdev, unsigned i,
[PATCH 1/3] drm/radeon: stop poisoning the GART TLB
From: Christian K?nig When we set the valid bit on invalid GART entries they are loaded into the TLB when an adjacent entry is loaded. This poisons the TLB with invalid entries which are sometimes not correctly removed on TLB flush. For stable inclusion the patch probably needs to be modified a bit. Signed-off-by: Christian K?nig Cc: stable at vger.kernel.org --- drivers/gpu/drm/radeon/rs600.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/rs600.c b/drivers/gpu/drm/radeon/rs600.c index 0a8be63..e0465b2 100644 --- a/drivers/gpu/drm/radeon/rs600.c +++ b/drivers/gpu/drm/radeon/rs600.c @@ -634,7 +634,10 @@ int rs600_gart_set_page(struct radeon_device *rdev, int i, uint64_t addr) return -EINVAL; } addr = addr & 0xF000ULL; - addr |= R600_PTE_GART; + if (addr == rdev->dummy_page.addr) + addr |= R600_PTE_SYSTEM | R600_PTE_SNOOPED; + else + addr |= R600_PTE_GART; writeq(addr, ptr + (i * 8)); return 0; } -- 1.9.1
[PATCH] drm/i915: Kick out vga console
On Wed, 04 Jun 2014, David Herrmann wrote:
> Hi
>
> On Wed, Jun 4, 2014 at 12:57 AM, Daniel Vetter
> wrote:
>> From: Chris Wilson
>>
>> Touching the VGA resources on an IVB EFI machine causes hard hangs when
>> we then kick out the efifb. Ouch.
>>
>> Apparently this also prevents unclaimed register errors on hsw and
>> hard machine hangs on my i855gm when trying to unbind fbcon.
>>
>> Also, we want this to make I915_FBDEV=n safe.
>>
>> v2: Rebase and pimp commit message.
>>
>> v3: We also need to unregister the vga console, otherwise the unbind
>> of the fb console before module unload might resurrect it again.
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67813
>> Cc: David Herrmann
>> Cc: Jean-Christophe Plagniol-Villard
>> Cc: Tomi Valkeinen
>> Cc: linux-fbdev at vger.kernel.org
>> Signed-off-by: Chris Wilson (v1)
>> Signed-off-by: Daniel Vetter
>> ---
>> drivers/gpu/drm/i915/i915_dma.c | 34 +-
>> drivers/video/console/dummycon.c | 1 +
>> drivers/video/console/vgacon.c | 1 +
>> 3 files changed, 35 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_dma.c
>> b/drivers/gpu/drm/i915/i915_dma.c
>> index b9159ade5e85..a4df80740b37 100644
>> --- a/drivers/gpu/drm/i915/i915_dma.c
>> +++ b/drivers/gpu/drm/i915/i915_dma.c
>> @@ -36,6 +36,8 @@
>> #include "i915_drv.h"
>> #include "i915_trace.h"
>> #include
>> +#include
>> +#include
>> #include
>> #include
>> #include
>> @@ -1450,6 +1452,29 @@ static void i915_kick_out_firmware_fb(struct
>> drm_i915_private *dev_priv)
>> }
>> #endif
>>
>> +static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
>> +{
>> +#if !defined(CONFIG_VGA_CONSOLE)
>> + return 0;
>> +#else
>> + int ret;
>> +
>> +#if !defined(CONFIG_DUMMY_CONSOLE)
>> + return -ENODEV;
>> +#endif
>> +
>> + DRM_INFO("Replacing VGA console driver\n");
>> +
>> + console_lock();
>> + ret = do_take_over_console(&dummy_con, 0, MAX_NR_CONSOLES - 1, 1);
>
> You rely on compiler-optimizations here. "dummy_con" is not available
> if !CONFIG_DUMMY_CONSOLE, but you use it. This causes linker-failure
> if dead-code elimination is not done (-O0).
Nested #ifs too. How about
#if !defined(CONFIG_VGA_CONSOLE)
static inline int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
{
return 0;
}
#elif !defined(CONFIG_DUMMY_CONSOLE)
static inline int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
{
return -ENODEV;
}
#else
static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
{
/* ... */
}
#endif
in proper kernel style?
BR,
Jani.
>
> Thanks
> David
>
>> + if (ret == 0)
>> + ret = do_unregister_con_driver(&vga_con);
>> + console_unlock();
>> +
>> + return ret;
>> +#endif
>> +}
>> +
>> static void i915_dump_device_info(struct drm_i915_private *dev_priv)
>> {
>> const struct intel_device_info *info = &dev_priv->info;
>> @@ -1623,8 +1648,15 @@ int i915_driver_load(struct drm_device *dev, unsigned
>> long flags)
>> if (ret)
>> goto out_regs;
>>
>> - if (drm_core_check_feature(dev, DRIVER_MODESET))
>> + if (drm_core_check_feature(dev, DRIVER_MODESET)) {
>> + ret = i915_kick_out_vgacon(dev_priv);
>> + if (ret) {
>> + DRM_ERROR("failed to remove conflicting VGA
>> console\n");
>> + goto out_gtt;
>> + }
>> +
>> i915_kick_out_firmware_fb(dev_priv);
>> + }
>>
>> pci_set_master(dev->pdev);
>>
>> diff --git a/drivers/video/console/dummycon.c
>> b/drivers/video/console/dummycon.c
>> index b63860f7beab..40bec8d64b0a 100644
>> --- a/drivers/video/console/dummycon.c
>> +++ b/drivers/video/console/dummycon.c
>> @@ -77,3 +77,4 @@ const struct consw dummy_con = {
>> .con_set_palette = DUMMY,
>> .con_scrolldelta = DUMMY,
>> };
>> +EXPORT_SYMBOL_GPL(dummy_con);
>> diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c
>> index 9d8feac67637..84acd6223dc5 100644
>> --- a/drivers/video/console/vgacon.c
>> +++ b/drivers/video/console/vgacon.c
>> @@ -1440,5 +1440,6 @@ const struct consw vga_con = {
>> .con_build_attr = vgacon_build_attr,
>> .con_invert_region = vgacon_invert_region,
>> };
>> +EXPORT_SYMBOL(vga_con);
>>
>> MODULE_LICENSE("GPL");
>> --
>> 1.8.1.4
>>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Jani Nikula, Intel Open Source Technology Center
[PATCH] drm/i915: Kick out vga console
Hi
On Wed, Jun 4, 2014 at 2:20 PM, Jani Nikula
wrote:
> On Wed, 04 Jun 2014, David Herrmann wrote:
>> You rely on compiler-optimizations here. "dummy_con" is not available
>> if !CONFIG_DUMMY_CONSOLE, but you use it. This causes linker-failure
>> if dead-code elimination is not done (-O0).
>
> Nested #ifs too. How about
>
> #if !defined(CONFIG_VGA_CONSOLE)
> static inline int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
> {
> return 0;
> }
> #elif !defined(CONFIG_DUMMY_CONSOLE)
> static inline int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
> {
> return -ENODEV;
> }
> #else
> static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
> {
> /* ... */
> }
> #endif
>
> in proper kernel style?
Or even shorter:
#if defined(CONFIG_VGA_CONSOLE) && defined(CONFIG_DUMMY_CONSOLE)
static inline int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
{
...
}
#else
static inline int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
{
return IS_ENABLED(CONFIG_VGA_CONSOLE) ? -ENODEV : 0;
}
#endif
Thanks
David
On Wed, Jun 4, 2014 at 2:20 PM, Jani Nikula
wrote:
> On Wed, 04 Jun 2014, David Herrmann wrote:
>> Hi
>>
>> On Wed, Jun 4, 2014 at 12:57 AM, Daniel Vetter
>> wrote:
>>> From: Chris Wilson
>>>
>>> Touching the VGA resources on an IVB EFI machine causes hard hangs when
>>> we then kick out the efifb. Ouch.
>>>
>>> Apparently this also prevents unclaimed register errors on hsw and
>>> hard machine hangs on my i855gm when trying to unbind fbcon.
>>>
>>> Also, we want this to make I915_FBDEV=n safe.
>>>
>>> v2: Rebase and pimp commit message.
>>>
>>> v3: We also need to unregister the vga console, otherwise the unbind
>>> of the fb console before module unload might resurrect it again.
>>>
>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67813
>>> Cc: David Herrmann
>>> Cc: Jean-Christophe Plagniol-Villard
>>> Cc: Tomi Valkeinen
>>> Cc: linux-fbdev at vger.kernel.org
>>> Signed-off-by: Chris Wilson (v1)
>>> Signed-off-by: Daniel Vetter
>>> ---
>>> drivers/gpu/drm/i915/i915_dma.c | 34 +-
>>> drivers/video/console/dummycon.c | 1 +
>>> drivers/video/console/vgacon.c | 1 +
>>> 3 files changed, 35 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_dma.c
>>> b/drivers/gpu/drm/i915/i915_dma.c
>>> index b9159ade5e85..a4df80740b37 100644
>>> --- a/drivers/gpu/drm/i915/i915_dma.c
>>> +++ b/drivers/gpu/drm/i915/i915_dma.c
>>> @@ -36,6 +36,8 @@
>>> #include "i915_drv.h"
>>> #include "i915_trace.h"
>>> #include
>>> +#include
>>> +#include
>>> #include
>>> #include
>>> #include
>>> @@ -1450,6 +1452,29 @@ static void i915_kick_out_firmware_fb(struct
>>> drm_i915_private *dev_priv)
>>> }
>>> #endif
>>>
>>> +static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
>>> +{
>>> +#if !defined(CONFIG_VGA_CONSOLE)
>>> + return 0;
>>> +#else
>>> + int ret;
>>> +
>>> +#if !defined(CONFIG_DUMMY_CONSOLE)
>>> + return -ENODEV;
>>> +#endif
>>> +
>>> + DRM_INFO("Replacing VGA console driver\n");
>>> +
>>> + console_lock();
>>> + ret = do_take_over_console(&dummy_con, 0, MAX_NR_CONSOLES - 1, 1);
>>
>> You rely on compiler-optimizations here. "dummy_con" is not available
>> if !CONFIG_DUMMY_CONSOLE, but you use it. This causes linker-failure
>> if dead-code elimination is not done (-O0).
>
> Nested #ifs too. How about
>
> #if !defined(CONFIG_VGA_CONSOLE)
> static inline int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
> {
> return 0;
> }
> #elif !defined(CONFIG_DUMMY_CONSOLE)
> static inline int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
> {
> return -ENODEV;
> }
> #else
> static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
> {
> /* ... */
> }
> #endif
>
> in proper kernel style?
>
> BR,
> Jani.
>
>
>>
>> Thanks
>> David
>>
>>> + if (ret == 0)
>>> + ret = do_unregister_con_driver(&vga_con);
>>> + console_unlock();
>>> +
>>> + return ret;
>>> +#endif
>>> +}
>>> +
>>> static void i915_dump_device_info(struct drm_i915_private *dev_priv)
>>> {
>>> const struct intel_device_info *info = &dev_priv->info;
>>> @@ -1623,8 +1648,15 @@ int i915_driver_load(struct drm_device *dev,
>>> unsigned long flags)
>>> if (ret)
>>> goto out_regs;
>>>
>>> - if (drm_core_check_feature(dev, DRIVER_MODESET))
>>> + if (drm_core_check_feature(dev, DRIVER_MODESET)) {
>>> + ret = i915_kick_out_vgacon(dev_priv);
>>> + if (ret) {
>>> + DRM_ERROR("failed to remove conflicting VGA
>>> console\n");
>>> + goto out_gtt;
>>> + }
>>> +
>>> i915_kick_out_firmware_fb(dev_priv);
>>> + }
>>>
>>> pci_set_master(dev->pdev);
>>>
>>> diff --git a/drivers/video/console/dummycon.c
>>> b/drivers/video/console/dum
[PATCH] gpu: drm: msm: Replace type of paddr to uint32_t.
>From e7147352639fd8f92b1cc85cff9bc5046c7a2130 Mon Sep 17 00:00:00 2001
From: "Matwey V. Kornilov"
Date: Mon, 2 Jun 2014 20:17:29 +0400
Subject: [PATCH] Replace type of paddr to uint32_t.
This patch helps to avoid the following build issue:
drivers/gpu/drm/msm/msm_fbdev.c:108:2: error: passing argument 3 of
'msm_gem_get_iova_locked' from incompatible pointer type [-Werror]
msm_gem_get_iova_locked(fbdev->bo, 0, &paddr);
^
In file included from drivers/gpu/drm/msm/msm_fbdev.c:18:0:
drivers/gpu/drm/msm/msm_drv.h:153:5: note: expected 'uint32_t *' but argument
is of type 'dma_addr_t *'
int msm_gem_get_iova_locked(struct drm_gem_object *obj, int id,
^
Signed-off-by: Matwey V. Kornilov
---
drivers/gpu/drm/msm/msm_fbdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_fbdev.c b/drivers/gpu/drm/msm/msm_fbdev.c
index a752ab8..5107fc4 100644
--- a/drivers/gpu/drm/msm/msm_fbdev.c
+++ b/drivers/gpu/drm/msm/msm_fbdev.c
@@ -59,7 +59,7 @@ static int msm_fbdev_create(struct drm_fb_helper *helper,
struct drm_framebuffer *fb = NULL;
struct fb_info *fbi = NULL;
struct drm_mode_fb_cmd2 mode_cmd = {0};
- dma_addr_t paddr;
+ uint32_t paddr;
int ret, size;
sizes->surface_bpp = 32;
--
1.9.3
[PATCH 7/8] drm: convert crtc and connection_mutex to ww_mutex (v3)
On 3 June 2014 23:29, Daniel Vetter wrote: > On Fri, May 30, 2014 at 01:12:09PM -0400, Rob Clark wrote: >> For atomic, it will be quite necessary to not need to care so much >> about locking order. And 'state' gives us a convenient place to stash a >> ww_ctx for any sort of update that needs to grab multiple crtc locks. >> >> Because we will want to eventually make locking even more fine grained >> (giving locks to planes, connectors, etc), split out drm_modeset_lock >> and drm_modeset_acquire_ctx to track acquired locks. >> >> Atomic will use this to keep track of which locks have been acquired >> in a transaction. >> >> v1: original >> v2: remove a few things not needed until atomic, for now >> v3: update for v3 of connection_mutex patch.. >> >> Signed-off-by: Rob Clark > > Still meh about the lock_all_crtcs helper, imo that one should die. But > one todo you've missed from my fixup patch is to add kerneldoc for all the > locking helpers (maybe that convinces you to inline lock_all_crtcs ;-) and > pull it into the drm docbook template. Otherwise nothing stuck out any > more. I'm happy to apply this one if we get some kerneldoc into it. I've applied the previous patches to drm-next, there was one conflict in i915, but I think I fixed it up okay, f7ef3fa77fa85b3a8a15b464efd56d0314a3231c was what it was conflicting with. Dave.
[Intel-gfx] [PATCH] drm: Move plane helpers into drm_kms_helper.ko
On 4 June 2014 03:30, Daniel Vetter wrote: > The drm core shouldn't depend upon any helpers, and we make sure this > doesn't accidentally happen by moving them into the helper-only > drm_kms_helper.ko module. > > v2: Don't break the build for vmwgfx, spotted by Matt. > > v3: Unbreak the depency loop around CONFIG_FB (not actually a loop > since it involves select). Reported by Chris. > > Cc: Matt Roper > Cc: Thomas Hellstrom > Cc: Chris Wilson > Signed-off-by: Daniel Vetter > --- > drivers/gpu/drm/Makefile | 6 +++--- > drivers/gpu/drm/vmwgfx/Kconfig | 7 +-- > 2 files changed, 8 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile > index 48e38ba22783..863db8415c22 100644 > --- a/drivers/gpu/drm/Makefile > +++ b/drivers/gpu/drm/Makefile > @@ -13,8 +13,7 @@ drm-y :=drm_auth.o drm_buffer.o drm_bufs.o > drm_cache.o \ > drm_crtc.o drm_modes.o drm_edid.o \ > drm_info.o drm_debugfs.o drm_encoder_slave.o \ > drm_trace_points.o drm_global.o drm_prime.o \ > - drm_rect.o drm_vma_manager.o drm_flip_work.o \ > - drm_plane_helper.o > + drm_rect.o drm_vma_manager.o drm_flip_work.o > > drm-$(CONFIG_COMPAT) += drm_ioc32.o > drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o > @@ -23,7 +22,8 @@ drm-$(CONFIG_DRM_PANEL) += drm_panel.o > > drm-usb-y := drm_usb.o > > -drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o > +drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \ > + drm_plane_helper.o > drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o > drm_kms_helper-$(CONFIG_DRM_KMS_FB_HELPER) += drm_fb_helper.o > drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o > diff --git a/drivers/gpu/drm/vmwgfx/Kconfig b/drivers/gpu/drm/vmwgfx/Kconfig > index b71bcd0bfbbf..67720f70fe29 100644 > --- a/drivers/gpu/drm/vmwgfx/Kconfig > +++ b/drivers/gpu/drm/vmwgfx/Kconfig > @@ -1,11 +1,14 @@ > config DRM_VMWGFX > tristate "DRM driver for VMware Virtual GPU" > - depends on DRM && PCI && FB > + depends on DRM && PCI > select FB_DEFERRED_IO > select FB_CFB_FILLRECT > select FB_CFB_COPYAREA > select FB_CFB_IMAGEBLIT > select DRM_TTM > + # Only needed for the transitional use of drm_crtc_init - can be > removed > + # again once vmwgfx sets up the primary plane itself. > + select DRM_KMS_HELPER > help > Choose this option if you would like to run 3D acceleration > in a VMware virtual machine. > @@ -14,7 +17,7 @@ config DRM_VMWGFX > The compiled module will be called "vmwgfx.ko". > > config DRM_VMWGFX_FBCON > - depends on DRM_VMWGFX > + depends on DRM_VMWGFX && FB > bool "Enable framebuffer console under vmwgfx by default" > help >Choose this option if you are shipping a new vmwgfx Applied thanks, Dave.
[PATCH v2] drm/exynos: consider deferred probe case
On 05/29/2014 11:28 AM, Inki Dae wrote:
> This patch makes sure that exynos drm framework handles deferred
> probe case correctly.
>
> Sub drivers could be probed before resources, clock, regulator,
> phy or panel, are ready for them so we should make sure that exynos
> drm core waits until all resources are ready and sub drivers are
> probed correctly.
>
> Chagelog v2:
> - Make sure that exynos drm core tries to bind sub drivers only in case that
> they have a pair: crtc and encoder/connector components should be a pair.
Do we really need it? It adds lot of code which in fact does not improve
exynos_drm - if some driver or device is missing drm will fail at load
or it will start with unusable pipeline anyway, the latter can be
changed to error as well.
> - Remove unnecessary patch:
> drm/exynos: mipi-dsi: consider panel driver-deferred probe
> - Return error type correctly.
>
> Signed-off-by: Inki Dae
> Acked-by: Kyungmin Park
> ---
> drivers/gpu/drm/exynos/exynos_dp_core.c | 18 +++-
> drivers/gpu/drm/exynos/exynos_drm_dpi.c | 22 -
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 139
> +-
> drivers/gpu/drm/exynos/exynos_drm_drv.h | 13 ++-
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 41 ++---
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 51 ---
> drivers/gpu/drm/exynos/exynos_hdmi.c | 78 -
> drivers/gpu/drm/exynos/exynos_mixer.c| 17 +++-
> 8 files changed, 304 insertions(+), 75 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> index ff63901..a892586 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
> @@ -1328,12 +1328,26 @@ static const struct component_ops exynos_dp_ops = {
>
> static int exynos_dp_probe(struct platform_device *pdev)
> {
> - return exynos_drm_component_add(&pdev->dev, &exynos_dp_ops);
> + int ret;
> +
> + ret = exynos_drm_component_add(&pdev->dev, EXYNOS_DEVICE_TYPE_CONNECTOR,
> + exynos_dp_display.type);
> + if (ret)
> + return ret;
> +
> + ret = component_add(&pdev->dev, &exynos_dp_ops);
> + if (ret)
> + exynos_drm_component_del(&pdev->dev,
> + EXYNOS_DEVICE_TYPE_CONNECTOR);
> +
> + return ret;
> }
>
> static int exynos_dp_remove(struct platform_device *pdev)
> {
> - exynos_drm_component_del(&pdev->dev, &exynos_dp_ops);
> + component_del(&pdev->dev, &exynos_dp_ops);
> + exynos_drm_component_del(&pdev->dev, EXYNOS_DEVICE_TYPE_CONNECTOR);
As I wrote in the previous comment calling exynos_drm_component_del here
will cause exynos_drv to stop waiting for exynos_dp to bring up drm
again, which is wrong. The same comment is valid for all other calls of
exynos_drm_component_del in *_remove and *_probe.
Or maybe I miss something???
> +
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
> b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
> index a832364..f1b8587 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
> @@ -295,9 +295,15 @@ struct exynos_drm_display *exynos_dpi_probe(struct
> device *dev)
> struct exynos_dpi *ctx;
> int ret;
>
> + ret = exynos_drm_component_add(dev,
> + EXYNOS_DEVICE_TYPE_CONNECTOR,
> + exynos_dpi_display.type);
> + if (ret)
> + return ERR_PTR(ret);
> +
> ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
> if (!ctx)
> - return NULL;
> + goto err_del_component;
>
> ctx->dev = dev;
> exynos_dpi_display.ctx = ctx;
> @@ -306,16 +312,24 @@ struct exynos_drm_display *exynos_dpi_probe(struct
> device *dev)
> ret = exynos_dpi_parse_dt(ctx);
> if (ret < 0) {
> devm_kfree(dev, ctx);
> - return NULL;
> + goto err_del_component;
> }
>
> if (ctx->panel_node) {
> ctx->panel = of_drm_find_panel(ctx->panel_node);
> - if (!ctx->panel)
> + if (!ctx->panel) {
> + exynos_drm_component_del(dev,
> + EXYNOS_DEVICE_TYPE_CONNECTOR);
> return ERR_PTR(-EPROBE_DEFER);
> + }
> }
>
> return &exynos_dpi_display;
> +
> +err_del_component:
> + exynos_drm_component_del(dev, EXYNOS_DEVICE_TYPE_CONNECTOR);
> +
> + return NULL;
> }
>
> int exynos_dpi_remove(struct device *dev)
> @@ -327,5 +341,7 @@ int exynos_dpi_remove(struct device *dev)
> encoder->funcs->destroy(encoder);
> drm_connector_cleanup(&ctx->connector);
>
> + exynos_drm_component_del(dev, EXYNOS_DEVICE_TYPE_CONNECTOR);
> +
> return 0;
> }
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>
[PATCH v2 0/8] drm & drivers: kill drm_get_connector_name() and drm_get_encoder_name()
On 3 June 2014 21:56, Jani Nikula wrote: > Hi all, this is v2 of [1] to remove drm_get_connector_name() and > drm_get_encoder_name(), adding patch 1 for imx in staging and making > some dereferences less of an eye sore. This is based on Dave's drm-next > branch. > I pushed these, after regenerating a couple of bits for new radeon and edid code. Thanks, Dave.
[PATCH v2 1/5] gpu: ipu-v3: Move i.MX IPUv3 core driver out of staging
On 3 June 2014 03:06, Greg Kroah-Hartman wrote: > On Mon, Jun 02, 2014 at 06:36:22PM +0200, Philipp Zabel wrote: >> Am Mittwoch, den 28.05.2014, 14:13 -0700 schrieb Greg Kroah-Hartman: >> > On Mon, May 26, 2014 at 04:19:39PM +0200, Philipp Zabel wrote: >> > > The i.MX Image Processing Unit (IPU) contains a number of image >> > > processing >> > > blocks that sit right in the middle between DRM and V4L2. Some of the >> > > modules, >> > > such as Display Controller, Processor, and Interface (DC, DP, DI) or CMOS >> > > Sensor Interface (CSI) and their FIFOs could be assigned to either >> > > framework, >> > > but others, such as the dma controller (IDMAC) and image converter (IC) >> > > can >> > > be used by both. >> > > The IPUv3 core driver provides an internal API to access the modules, to >> > > be >> > > used by both DRM and V4L2 IPUv3 drivers. >> > > >> > > Signed-off-by: Lucas Stach >> > > Signed-off-by: Philipp Zabel >> > > --- >> > > Changes since RFC: >> > > - Rebased onto current staging-next >> > > - Removed an unrelated change to ipu_pixelformat_to_colorspace >> > > - Avoided moving around the IPU_PIX_FMT_GBR24 #define >> > >> > Acked-by: Greg Kroah-Hartman >> >> Thank you. My favourite next step would be to send a pull request and >> have this merged into drm-next. Dave, Greg would you be ok with this? > > No objection from me, it's up to Dave what he wants for this. Yes please send me a pull req for this. Dave.
[PATCH 1/4] drm/radeon: rename alt_domain to allowed_domains
Am 02.06.2014 17:52, schrieb Alex Deucher:
> On Mon, Jun 2, 2014 at 11:33 AM, Christian K?nig
> wrote:
>> From: Christian K?nig
>>
>> And also domain to prefered_domains. That matches better
>> what those values represent.
>>
>> Signed-off-by: Christian K?nig
>> Cc: Marek Ol??k
> A couple of comments on 2/4, but other than that, the series is:
>
> Reviewed-by: Alex Deucher
It looks like your comments on #4 never made it to me, could you resend
them?
Thanks,
Christian.
>
>> ---
>> drivers/gpu/drm/radeon/radeon.h| 4 ++--
>> drivers/gpu/drm/radeon/radeon_cs.c | 8
>> drivers/gpu/drm/radeon/radeon_object.c | 9 +
>> drivers/gpu/drm/radeon/radeon_vm.c | 8
>> 4 files changed, 15 insertions(+), 14 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon.h
>> b/drivers/gpu/drm/radeon/radeon.h
>> index 7501ba31..babb7f1 100644
>> --- a/drivers/gpu/drm/radeon/radeon.h
>> +++ b/drivers/gpu/drm/radeon/radeon.h
>> @@ -997,8 +997,8 @@ struct radeon_cs_reloc {
>> struct radeon_bo*robj;
>> struct ttm_validate_buffer tv;
>> uint64_tgpu_offset;
>> - unsigneddomain;
>> - unsignedalt_domain;
>> + unsignedprefered_domains;
>> + unsignedallowed_domains;
>> uint32_ttiling_flags;
>> uint32_thandle;
>> };
>> diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
>> b/drivers/gpu/drm/radeon/radeon_cs.c
>> index 41ecf8a..71a1434 100644
>> --- a/drivers/gpu/drm/radeon/radeon_cs.c
>> +++ b/drivers/gpu/drm/radeon/radeon_cs.c
>> @@ -140,10 +140,10 @@ static int radeon_cs_parser_relocs(struct
>> radeon_cs_parser *p)
>> if (p->ring == R600_RING_TYPE_UVD_INDEX &&
>> (i == 0 || drm_pci_device_is_agp(p->rdev->ddev))) {
>> /* TODO: is this still needed for NI+ ? */
>> - p->relocs[i].domain =
>> + p->relocs[i].prefered_domains =
>> RADEON_GEM_DOMAIN_VRAM;
>>
>> - p->relocs[i].alt_domain =
>> + p->relocs[i].allowed_domains =
>> RADEON_GEM_DOMAIN_VRAM;
>>
>> /* prioritize this over any other relocation */
>> @@ -158,10 +158,10 @@ static int radeon_cs_parser_relocs(struct
>> radeon_cs_parser *p)
>> return -EINVAL;
>> }
>>
>> - p->relocs[i].domain = domain;
>> + p->relocs[i].prefered_domains = domain;
>> if (domain == RADEON_GEM_DOMAIN_VRAM)
>> domain |= RADEON_GEM_DOMAIN_GTT;
>> - p->relocs[i].alt_domain = domain;
>> + p->relocs[i].allowed_domains = domain;
>> }
>>
>> p->relocs[i].tv.bo = &p->relocs[i].robj->tbo;
>> diff --git a/drivers/gpu/drm/radeon/radeon_object.c
>> b/drivers/gpu/drm/radeon/radeon_object.c
>> index 2918087..6c717b2 100644
>> --- a/drivers/gpu/drm/radeon/radeon_object.c
>> +++ b/drivers/gpu/drm/radeon/radeon_object.c
>> @@ -446,7 +446,7 @@ int radeon_bo_list_validate(struct radeon_device *rdev,
>> list_for_each_entry(lobj, head, tv.head) {
>> bo = lobj->robj;
>> if (!bo->pin_count) {
>> - u32 domain = lobj->domain;
>> + u32 domain = lobj->prefered_domains;
>> u32 current_domain =
>>
>> radeon_mem_type_to_domain(bo->tbo.mem.mem_type);
>>
>> @@ -458,7 +458,7 @@ int radeon_bo_list_validate(struct radeon_device *rdev,
>> * into account. We don't want to disallow buffer
>> moves
>> * completely.
>> */
>> - if ((lobj->alt_domain & current_domain) != 0 &&
>> + if ((lobj->allowed_domains & current_domain) != 0 &&
>> (domain & current_domain) == 0 && /* will be
>> moved */
>> bytes_moved > bytes_moved_threshold) {
>> /* don't move it */
>> @@ -476,8 +476,9 @@ int radeon_bo_list_validate(struct radeon_device *rdev,
>> initial_bytes_moved;
>>
>> if (unlikely(r)) {
>> - if (r != -ERESTARTSYS && domain !=
>> lobj->alt_domain) {
>> - domain = lobj->alt_domain;
>> + if (r != -ERESTARTSYS &&
>> + domain != lobj->allowed_domains) {
>> + domain = lobj->allowed_domains;
>>
[Bug 79520] mpv 0.3.10-1 shows no video after mesa and ati-dri update to version 10.2.0rc5-1
https://bugs.freedesktop.org/show_bug.cgi?id=79520
--- Comment #14 from Savyasachee Jha ---
(In reply to comment #13)
> (In reply to comment #12)
> > (In reply to comment #11)
> > > FYI if you're using VDPAU, setting LD_LIBRARY_PATH and LIBGL_DRIVERS_PATH
> > > will not work. The libvdpau library is hardcoded to search for
> > > /usr/lib/vdpau/${driver}_vdpau.so.
> > >
> > > There are two ways around this - rebuild libvdpau with this commit [1] and
> > > set VDPAU_DRIVER_PATH or symlink/install the library.
> > >
> > > [1]
> > > http://cgit.freedesktop.org/~aplattner/libvdpau/commit/
> > > ?id=ee9491a1216f47e10cbb551391a01c7fcde940d2
> >
> > I'm using the vo=opengl option in mpv.
>
> Yeah, but you are using the VDPAU hardware acceleration.
Ah. Okay, I got it. I need to leave this particular laptop right now, so I
can't do that atm. I'll have it done tomorrow. Thanks for all the help and the
patience.
--
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/20140604/7163ce67/attachment.html>
[Bug 79520] mpv 0.3.10-1 shows no video after mesa and ati-dri update to version 10.2.0rc5-1
https://bugs.freedesktop.org/show_bug.cgi?id=79520
--- Comment #13 from Christian K?nig ---
(In reply to comment #12)
> (In reply to comment #11)
> > FYI if you're using VDPAU, setting LD_LIBRARY_PATH and LIBGL_DRIVERS_PATH
> > will not work. The libvdpau library is hardcoded to search for
> > /usr/lib/vdpau/${driver}_vdpau.so.
> >
> > There are two ways around this - rebuild libvdpau with this commit [1] and
> > set VDPAU_DRIVER_PATH or symlink/install the library.
> >
> > [1]
> > http://cgit.freedesktop.org/~aplattner/libvdpau/commit/
> > ?id=ee9491a1216f47e10cbb551391a01c7fcde940d2
>
> I'm using the vo=opengl option in mpv.
Yeah, but you are using the VDPAU hardware acceleration.
--
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/20140604/931fa1a4/attachment.html>
[Bug 79520] mpv 0.3.10-1 shows no video after mesa and ati-dri update to version 10.2.0rc5-1
https://bugs.freedesktop.org/show_bug.cgi?id=79520
--- Comment #12 from Savyasachee Jha ---
(In reply to comment #11)
> FYI if you're using VDPAU, setting LD_LIBRARY_PATH and LIBGL_DRIVERS_PATH
> will not work. The libvdpau library is hardcoded to search for
> /usr/lib/vdpau/${driver}_vdpau.so.
>
> There are two ways around this - rebuild libvdpau with this commit [1] and
> set VDPAU_DRIVER_PATH or symlink/install the library.
>
> [1]
> http://cgit.freedesktop.org/~aplattner/libvdpau/commit/
> ?id=ee9491a1216f47e10cbb551391a01c7fcde940d2
I'm using the vo=opengl option in mpv.
--
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/20140604/d5f32c74/attachment.html>
[Bug 79520] mpv 0.3.10-1 shows no video after mesa and ati-dri update to version 10.2.0rc5-1
https://bugs.freedesktop.org/show_bug.cgi?id=79520
--- Comment #11 from Emil Velikov ---
FYI if you're using VDPAU, setting LD_LIBRARY_PATH and LIBGL_DRIVERS_PATH will
not work. The libvdpau library is hardcoded to search for
/usr/lib/vdpau/${driver}_vdpau.so.
There are two ways around this - rebuild libvdpau with this commit [1] and set
VDPAU_DRIVER_PATH or symlink/install the library.
[1]
http://cgit.freedesktop.org/~aplattner/libvdpau/commit/?id=ee9491a1216f47e10cbb551391a01c7fcde940d2
--
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/20140604/949d33c3/attachment.html>
[PATCH] drm/radeon: add missing vce init case for hawaii
Hawaii has the same version of VCE as other CIK parts. Signed-off-by: Alex Deucher Cc: stable at vger.kernel.org --- drivers/gpu/drm/radeon/radeon_vce.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/radeon/radeon_vce.c b/drivers/gpu/drm/radeon/radeon_vce.c index ced53dd..1c5dd95 100644 --- a/drivers/gpu/drm/radeon/radeon_vce.c +++ b/drivers/gpu/drm/radeon/radeon_vce.c @@ -66,6 +66,7 @@ int radeon_vce_init(struct radeon_device *rdev) case CHIP_BONAIRE: case CHIP_KAVERI: case CHIP_KABINI: + case CHIP_HAWAII: fw_name = FIRMWARE_BONAIRE; break; -- 1.8.3.1
[PATCH qxl.ko] Use surface_id 0 for primary surface on all monitors
I've hand fixed this up and applied it, but please in future submit patches using the guidelines in Documentation/SubmittingPatches. Dave. On 4 June 2014 00:56, David Mansfield wrote: > spice-server and downstream code expect that the primary surface > will always have surface_id = 0, while in reality, once allocated, the > surface_id in qxl.ko is NEVER 0. In a dual head environment, all > monitors render portions of the primary surface. > > However, when the monitor config events are generated and sent, > the primary surface is only mapped to the correct identifier > (i.e. 0) for the primary head (where crtc index is 0). > > The fix is to look at the "primary" flag in the bo and always > use id 0, irrespective of which head is being configured. > I've hand fixed this up and applied it, but please in future submit patches using the guidelines in Documentation/SubmittingPatches. Dave.
[pull] radeon drm-next-3.16
On 3 June 2014 23:03, Christian K?nig wrote: > Am 03.06.2014 14:58, schrieb Alex Deucher: > >> On Mon, Jun 2, 2014 at 11:21 PM, Michel D?nzer wrote: >>> >>> On 03.06.2014 07:55, Alex Deucher wrote: This is the first pull request for radeon for 3.16. Christian has a few other patches that depend on some fixes from 3.15 so I'll wait to send those out until you sort out the 3.15 merge. >>> >>> [...] >>> Christian K?nig (10): >>> >>> [...] drm/radeon: rework page flip handling v3 >>> >>> This one shouldn't be merged without my review comment being addressed. >> >> Sorry Michel, I completely forgot about your comments. Christian, >> have you had a chance to look at them? I can respin without this >> patch set if you need more time. > > > Please drop it for now. I'm still busy with the CIK issue, so it might take > a while till I get back to it. > > On the other hand Michels comment can be fixed trivially, feel free to do so > and send the result to Dave. I reverted the v3 and applied v4 into drm-next. Dave.
[PULL] Move IPUv3 core out of staging, add CSI support
Hi Dave,
The following changes since commit d1db0eea852497762cab43b905b879dfcd3b8987:
Linux 3.15-rc3 (2014-04-27 19:29:27 -0700)
are available in the git repository at:
git://git.pengutronix.de/git/pza/linux.git topic/ipu-destaging
for you to fetch changes up to d6ca8ca7ec555bdd3372687d0d775c837a09ff6e:
gpu: ipu-v3: Register the CSI modules (2014-06-04 11:07:12 +0200)
These move the core i.MX IPU code out of staging into drivers/gpu and add
the foundation for CSI capture support. In the following round we can then
fix remaining issues with imx-drm in staging and start adding V4L2 support
in parallel.
I have rebased the series back to v3.15-rc3, the tag closest to the common
ancestor of drm-next and staging-next, and verified that merging the two
produces the correct result.
regards
Philipp
Philipp Zabel (5):
gpu: ipu-v3: Move i.MX IPUv3 core driver out of staging
gpu: ipu-v3: Add SMFC code
gpu: ipu-v3: Add ipu_idmac_get_current_buffer function
gpu: ipu-v3: Add CSI and SMFC module enable wrappers
gpu: ipu-v3: Register the CSI modules
drivers/gpu/Makefile | 1 +
drivers/gpu/ipu-v3/Kconfig | 7 ++
drivers/{staging/imx-drm => gpu}/ipu-v3/Makefile | 4 +-
.../{staging/imx-drm => gpu}/ipu-v3/ipu-common.c | 82 --
drivers/{staging/imx-drm => gpu}/ipu-v3/ipu-dc.c | 3 +-
drivers/{staging/imx-drm => gpu}/ipu-v3/ipu-di.c | 2 +-
drivers/{staging/imx-drm => gpu}/ipu-v3/ipu-dmfc.c | 2 +-
drivers/{staging/imx-drm => gpu}/ipu-v3/ipu-dp.c | 2 +-
drivers/{staging/imx-drm => gpu}/ipu-v3/ipu-prv.h | 8 +-
drivers/gpu/ipu-v3/ipu-smfc.c | 97 ++
drivers/staging/imx-drm/Kconfig| 11 +--
drivers/staging/imx-drm/Makefile | 1 -
drivers/staging/imx-drm/imx-hdmi.c | 2 +-
drivers/staging/imx-drm/imx-tve.c | 2 +-
drivers/staging/imx-drm/ipuv3-crtc.c | 2 +-
drivers/staging/imx-drm/ipuv3-plane.c | 2 +-
drivers/video/Kconfig | 1 +
.../imx-drm/ipu-v3 => include/video}/imx-ipu-v3.h | 16
18 files changed, 216 insertions(+), 29 deletions(-)
create mode 100644 drivers/gpu/ipu-v3/Kconfig
rename drivers/{staging/imx-drm => gpu}/ipu-v3/Makefile (51%)
rename drivers/{staging/imx-drm => gpu}/ipu-v3/ipu-common.c (94%)
rename drivers/{staging/imx-drm => gpu}/ipu-v3/ipu-dc.c (99%)
rename drivers/{staging/imx-drm => gpu}/ipu-v3/ipu-di.c (99%)
rename drivers/{staging/imx-drm => gpu}/ipu-v3/ipu-dmfc.c (99%)
rename drivers/{staging/imx-drm => gpu}/ipu-v3/ipu-dp.c (99%)
rename drivers/{staging/imx-drm => gpu}/ipu-v3/ipu-prv.h (96%)
create mode 100644 drivers/gpu/ipu-v3/ipu-smfc.c
rename {drivers/staging/imx-drm/ipu-v3 => include/video}/imx-ipu-v3.h (95%)
[PATCH] drm/i915: Kick out vga console
Hi
On Wed, Jun 4, 2014 at 12:57 AM, Daniel Vetter
wrote:
> From: Chris Wilson
>
> Touching the VGA resources on an IVB EFI machine causes hard hangs when
> we then kick out the efifb. Ouch.
>
> Apparently this also prevents unclaimed register errors on hsw and
> hard machine hangs on my i855gm when trying to unbind fbcon.
>
> Also, we want this to make I915_FBDEV=n safe.
>
> v2: Rebase and pimp commit message.
>
> v3: We also need to unregister the vga console, otherwise the unbind
> of the fb console before module unload might resurrect it again.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67813
> Cc: David Herrmann
> Cc: Jean-Christophe Plagniol-Villard
> Cc: Tomi Valkeinen
> Cc: linux-fbdev at vger.kernel.org
> Signed-off-by: Chris Wilson (v1)
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_dma.c | 34 +-
> drivers/video/console/dummycon.c | 1 +
> drivers/video/console/vgacon.c | 1 +
> 3 files changed, 35 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index b9159ade5e85..a4df80740b37 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -36,6 +36,8 @@
> #include "i915_drv.h"
> #include "i915_trace.h"
> #include
> +#include
> +#include
> #include
> #include
> #include
> @@ -1450,6 +1452,29 @@ static void i915_kick_out_firmware_fb(struct
> drm_i915_private *dev_priv)
> }
> #endif
>
> +static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
> +{
> +#if !defined(CONFIG_VGA_CONSOLE)
> + return 0;
> +#else
> + int ret;
> +
> +#if !defined(CONFIG_DUMMY_CONSOLE)
> + return -ENODEV;
> +#endif
> +
> + DRM_INFO("Replacing VGA console driver\n");
> +
> + console_lock();
> + ret = do_take_over_console(&dummy_con, 0, MAX_NR_CONSOLES - 1, 1);
You rely on compiler-optimizations here. "dummy_con" is not available
if !CONFIG_DUMMY_CONSOLE, but you use it. This causes linker-failure
if dead-code elimination is not done (-O0).
Thanks
David
> + if (ret == 0)
> + ret = do_unregister_con_driver(&vga_con);
> + console_unlock();
> +
> + return ret;
> +#endif
> +}
> +
> static void i915_dump_device_info(struct drm_i915_private *dev_priv)
> {
> const struct intel_device_info *info = &dev_priv->info;
> @@ -1623,8 +1648,15 @@ int i915_driver_load(struct drm_device *dev, unsigned
> long flags)
> if (ret)
> goto out_regs;
>
> - if (drm_core_check_feature(dev, DRIVER_MODESET))
> + if (drm_core_check_feature(dev, DRIVER_MODESET)) {
> + ret = i915_kick_out_vgacon(dev_priv);
> + if (ret) {
> + DRM_ERROR("failed to remove conflicting VGA
> console\n");
> + goto out_gtt;
> + }
> +
> i915_kick_out_firmware_fb(dev_priv);
> + }
>
> pci_set_master(dev->pdev);
>
> diff --git a/drivers/video/console/dummycon.c
> b/drivers/video/console/dummycon.c
> index b63860f7beab..40bec8d64b0a 100644
> --- a/drivers/video/console/dummycon.c
> +++ b/drivers/video/console/dummycon.c
> @@ -77,3 +77,4 @@ const struct consw dummy_con = {
> .con_set_palette = DUMMY,
> .con_scrolldelta = DUMMY,
> };
> +EXPORT_SYMBOL_GPL(dummy_con);
> diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c
> index 9d8feac67637..84acd6223dc5 100644
> --- a/drivers/video/console/vgacon.c
> +++ b/drivers/video/console/vgacon.c
> @@ -1440,5 +1440,6 @@ const struct consw vga_con = {
> .con_build_attr = vgacon_build_attr,
> .con_invert_region = vgacon_invert_region,
> };
> +EXPORT_SYMBOL(vga_con);
>
> MODULE_LICENSE("GPL");
> --
> 1.8.1.4
>
[PATCH] drm/dp: add a hw mutex around the transfer functions.
On Wed, Jun 04, 2014 at 04:04:25PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> This should avoid races between connector probing and HPD
> irqs in the future, currently mode_config.mutex blocks this
> possibility.
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/drm_dp_helper.c | 15 +++
> drivers/gpu/drm/i915/intel_dp.c | 1 +
> drivers/gpu/drm/radeon/atombios_dp.c | 2 ++
> drivers/gpu/drm/tegra/dpaux.c| 1 +
> include/drm/drm_dp_helper.h | 3 ++-
> 5 files changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 494219c..cb687f4 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -382,7 +382,10 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8
> request,
>* transactions.
>*/
> for (retry = 0; retry < 7; retry++) {
> +
> + mutex_lock(&aux->hw_mutex);
> err = aux->transfer(aux, &msg);
> + mutex_unlock(&aux->hw_mutex);
> if (err < 0) {
> if (err == -EBUSY)
> continue;
> @@ -596,7 +599,9 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux,
> struct drm_dp_aux_msg *msg)
>* before giving up the AUX transaction.
>*/
> for (retry = 0; retry < 7; retry++) {
> + mutex_lock(&aux->hw_mutex);
> err = aux->transfer(aux, msg);
> + mutex_unlock(&aux->hw_mutex);
> if (err < 0) {
> if (err == -EBUSY)
> continue;
> @@ -761,3 +766,13 @@ void drm_dp_aux_unregister_i2c_bus(struct drm_dp_aux
> *aux)
> i2c_del_adapter(&aux->ddc);
> }
> EXPORT_SYMBOL(drm_dp_aux_unregister_i2c_bus);
> +
> +/**
> + * drm_dp_aux_init() - init a DP aux internal structure.
> + * @aux: DisplayPort AUX channel
> + */
> +void drm_dp_aux_init(struct drm_dp_aux *aux)
> +{
> + mutex_init(&aux->hw_mutex);
> +}
Imo we should merge this with drm_dp_aux_register (and drop the i2c_bus
part of it since it'll be more generic) - no driver should call one
without the other.
With that address this is Reviewed-by: Daniel Vetter
> +EXPORT_SYMBOL(drm_dp_aux_init);
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index c4d8839..aa99dcb 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -698,6 +698,7 @@ intel_dp_aux_init(struct intel_dp *intel_dp, struct
> intel_connector *connector)
> intel_dp->aux.name = name;
> intel_dp->aux.dev = dev->dev;
> intel_dp->aux.transfer = intel_dp_aux_transfer;
> + drm_dp_aux_init(&intel_dp->aux);
>
> DRM_DEBUG_KMS("registering %s bus for %s\n", name,
> connector->base.kdev->kobj.name);
> diff --git a/drivers/gpu/drm/radeon/atombios_dp.c
> b/drivers/gpu/drm/radeon/atombios_dp.c
> index 225f6c6..12d8784 100644
> --- a/drivers/gpu/drm/radeon/atombios_dp.c
> +++ b/drivers/gpu/drm/radeon/atombios_dp.c
> @@ -222,6 +222,8 @@ void radeon_dp_aux_init(struct radeon_connector
> *radeon_connector)
> radeon_connector->ddc_bus->rec.hpd = radeon_connector->hpd.hpd;
> radeon_connector->ddc_bus->aux.dev = radeon_connector->base.kdev;
> radeon_connector->ddc_bus->aux.transfer = radeon_dp_aux_transfer;
> +
> + drm_dp_aux_init(&radeon_connector->ddc_bus->aux);
> ret = drm_dp_aux_register_i2c_bus(&radeon_connector->ddc_bus->aux);
> if (!ret)
> radeon_connector->ddc_bus->has_aux = true;
> diff --git a/drivers/gpu/drm/tegra/dpaux.c b/drivers/gpu/drm/tegra/dpaux.c
> index 005c19b..98cd70b 100644
> --- a/drivers/gpu/drm/tegra/dpaux.c
> +++ b/drivers/gpu/drm/tegra/dpaux.c
> @@ -331,6 +331,7 @@ static int tegra_dpaux_probe(struct platform_device *pdev)
>
> dpaux->aux.transfer = tegra_dpaux_transfer;
> dpaux->aux.dev = &pdev->dev;
> + drm_dp_aux_init(&dpaux->aux);
>
> err = drm_dp_aux_register_i2c_bus(&dpaux->aux);
> if (err < 0)
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 488b416..09eee36 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -546,7 +546,7 @@ struct drm_dp_aux {
> const char *name;
> struct i2c_adapter ddc;
> struct device *dev;
> -
> + struct mutex hw_mutex;
> ssize_t (*transfer)(struct drm_dp_aux *aux,
> struct drm_dp_aux_msg *msg);
> };
> @@ -607,5 +607,6 @@ int drm_dp_link_configure(struct drm_dp_aux *aux, struct
> drm_dp_link *link);
>
> int drm_dp_aux_register_i2c_bus(struct drm_dp_aux *aux);
> void drm_dp_aux_unregister_i2c_bus(struct drm_dp_aux *aux);
> +void drm_dp_aux_init(struct drm_dp_aux *aux);
>
> #endif /* _DRM_DP_HELPER_H_ */
> --
> 1.9.3
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.o
[PATCH 7/8] drm: convert crtc and connection_mutex to ww_mutex (v3)
On Wed, Jun 04, 2014 at 01:38:38PM +1000, Dave Airlie wrote: > On 3 June 2014 23:29, Daniel Vetter wrote: > > On Fri, May 30, 2014 at 01:12:09PM -0400, Rob Clark wrote: > >> For atomic, it will be quite necessary to not need to care so much > >> about locking order. And 'state' gives us a convenient place to stash a > >> ww_ctx for any sort of update that needs to grab multiple crtc locks. > >> > >> Because we will want to eventually make locking even more fine grained > >> (giving locks to planes, connectors, etc), split out drm_modeset_lock > >> and drm_modeset_acquire_ctx to track acquired locks. > >> > >> Atomic will use this to keep track of which locks have been acquired > >> in a transaction. > >> > >> v1: original > >> v2: remove a few things not needed until atomic, for now > >> v3: update for v3 of connection_mutex patch.. > >> > >> Signed-off-by: Rob Clark > > > > Still meh about the lock_all_crtcs helper, imo that one should die. But > > one todo you've missed from my fixup patch is to add kerneldoc for all the > > locking helpers (maybe that convinces you to inline lock_all_crtcs ;-) and > > pull it into the drm docbook template. Otherwise nothing stuck out any > > more. > > I'm happy to apply this one if we get some kerneldoc into it. > > I've applied the previous patches to drm-next, there was one conflict in i915, > but I think I fixed it up okay, f7ef3fa77fa85b3a8a15b464efd56d0314a3231c > was what it was conflicting with. Yeah, I've done the modeset_lock_all specifically because of that conflict, so looks good. Could have dropped the braces too ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 79520] mpv 0.3.10-1 shows no video after mesa and ati-dri update to version 10.2.0rc5-1
https://bugs.freedesktop.org/show_bug.cgi?id=79520 --- Comment #10 from Savyasachee Jha --- (In reply to comment #7) > Can you get the backtrace of the segmentation fault? I ran it through gdb (commit number: ee978aee94d98fec669002eb5ef7ceb1f46683a9): [vader ~/Builds/cleandir/mesa]% systemd-coredumpctl gdb TIME PID UID GID SIG EXE Wed 2014-06-04 18:44:36 JST 22401 1000 100 11 /home/vader/Builds/mpv-git/src/mpv/build/.conf_check_b4d8c0b22f0a39cf01e84c4b2bf64f50/testbuild/testprog GNU gdb (GDB) 7.7.1 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-unknown-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /home/vader/Builds/mpv-git/src/mpv/build/.conf_check_b4d8c0b22f0a39cf01e84c4b2bf64f50/testbuild/testprog...done. [New LWP 22401] warning: Could not load shared library symbols for linux-vdso.so.1. Do you need "set solib-search-path" or "set sysroot"? [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". Core was generated by `/home/vader/Builds/mpv-git/src/mpv/build/.conf_check_b4d8c0b22f0a39cf01e84c4b2b'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x7f0e85fcd452 in ?? () from /usr/lib/liblua.so.5.2 -- 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/20140604/02c10bfe/attachment.html>
[Intel-gfx] [PATCH 6/6] drm/i915: Switch to unified plane cursor handling (v4)
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Matt Roper
Sent: Friday, May 23, 2014 2:30 AM
To: dri-devel at lists.freedesktop.org
Cc: intel-gfx at lists.freedesktop.org
Subject: [Intel-gfx] [PATCH 6/6] drm/i915: Switch to unified plane cursor
handling (v4)
The DRM core will translate calls to legacy cursor ioctls into universal cursor
calls automatically, so there's no need to maintain the legacy cursor support.
This greatly simplifies the transition since we don't have to handle reference
counting differently depending on which cursor interface was called.
The aim here is to transition to the universal plane interface with minimal
code change. There's a lot of cleanup that can be done (e.g., using state
stored in crtc->cursor->fb rather than intel_crtc) that is left to future
patches.
v4:
- Drop drm_gem_object_unreference() that is no longer needed now that
we receive the GEM obj directly rather than looking up the ID.
v3:
- Pass cursor obj to intel_crtc_cursor_set_obj() if cursor fb changes,
even if 'visible' is false. intel_crtc_cursor_set_obj() will notice
that the cursor isn't visible and disable it properly, but we still
need to get intel_crtc->cursor_addr set properly so that we behave
properly if the cursor becomes visible again in the future without
changing the cursor buffer (noted by Chris Wilson and verified
via i-g-t kms_cursor_crc).
- s/drm_plane_init/drm_universal_plane_init/. Due to type
compatibility between enum and bool, everything actually works
correctly with the wrong init call, except for the type of plane that
gets exposed to userspace (it shows up as type 'primary' rather than
type 'cursor').
v2:
- Remove duplicate dimension checks on cursor
- Drop explicit cursor disable from crtc destroy (fb & plane
destruction will take care of that now)
- Use DRM plane helper to check update parameters
Cc: intel-gfx at lists.freedesktop.org
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_display.c | 166 +--
drivers/gpu/drm/i915/intel_drv.h | 1 -
2 files changed, 118 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 6156741..8141520 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -68,6 +68,11 @@ static const uint32_t intel_primary_formats_gen4[] = {
DRM_FORMAT_ABGR2101010,
};
+/* Cursor formats */
+static const uint32_t intel_cursor_formats[] = {
+ DRM_FORMAT_ARGB,
+};
+
Is this the only format supported by cursor plane?
#define DIV_ROUND_CLOSEST_ULL(ll, d) \
({ unsigned long long _tmp = (ll)+(d)/2; do_div(_tmp, d); _tmp; })
@@ -7993,8 +7998,8 @@ static void intel_crtc_update_cursor(struct drm_crtc
*crtc,
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
int pipe = intel_crtc->pipe;
- int x = intel_crtc->cursor_x;
- int y = intel_crtc->cursor_y;
+ int x = crtc->cursor_x;
+ int y = crtc->cursor_y;
u32 base = 0, pos = 0;
bool visible;
@@ -8135,7 +8140,6 @@ static int intel_crtc_cursor_set_obj(struct drm_crtc
*crtc,
i915_gem_detach_phys_object(dev,
intel_crtc->cursor_bo);
} else
i915_gem_object_unpin_from_display_plane(intel_crtc->cursor_bo);
- drm_gem_object_unreference(&intel_crtc->cursor_bo->base);
}
mutex_unlock(&dev->struct_mutex);
@@ -8163,38 +8167,6 @@ fail:
return ret;
}
-static int intel_crtc_cursor_set(struct drm_crtc *crtc,
-struct drm_file *file,
-uint32_t handle,
-uint32_t width, uint32_t height)
-{
- struct drm_device *dev = crtc->dev;
- struct drm_i915_gem_object *obj;
-
- if (handle) {
- obj = to_intel_bo(drm_gem_object_lookup(dev, file, handle));
- if (&obj->base == NULL)
- return -ENOENT;
- } else {
- obj = NULL;
- }
-
- return intel_crtc_cursor_set_obj(crtc, obj, width, height);
-}
-
-static int intel_crtc_cursor_move(struct drm_crtc *crtc, int x, int y) -{
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-
- intel_crtc->cursor_x = clamp_t(int, x, SHRT_MIN, SHRT_MAX);
- intel_crtc->cursor_y = clamp_t(int, y, SHRT_MIN, SHRT_MAX);
-
- if (intel_crtc->active)
- intel_crtc_update_cursor(crtc, intel_crtc->cursor_bo != NULL);
-
- return 0;
-}
-
static void intel_crtc_gamma_set(struct drm_crtc *crtc, u16 *red, u16 *green,
u16 *blue, uint32_t start, uint32_t size) {
@@ -8816,8 +8788,6 @@ static void intel_crtc_destroy(struct drm_crtc *crtc)
kfre
[PATCH 2/2] drm: add drm_fb_helper_restore_fbdev_mode_unlocked()
All drm_fb_helper_restore_fbdev_mode() call sites, save one, do the same
locking. Simplify this into drm_fb_helper_restore_fbdev_mode_unlocked().
Signed-off-by: Rob Clark
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/armada/armada_fbdev.c | 4 +--
drivers/gpu/drm/drm_fb_cma_helper.c | 9 ++
drivers/gpu/drm/drm_fb_helper.c | 50 ++-
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 4 +--
drivers/gpu/drm/gma500/psb_drv.c | 4 +--
drivers/gpu/drm/i915/intel_fbdev.c| 6 +---
drivers/gpu/drm/msm/msm_drv.c | 7 ++---
drivers/gpu/drm/omapdrm/omap_drv.c| 4 +--
drivers/gpu/drm/tegra/fb.c| 7 ++---
include/drm/drm_fb_helper.h | 2 +-
10 files changed, 48 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_fbdev.c
b/drivers/gpu/drm/armada/armada_fbdev.c
index 948cb14..fd166f5 100644
--- a/drivers/gpu/drm/armada/armada_fbdev.c
+++ b/drivers/gpu/drm/armada/armada_fbdev.c
@@ -181,10 +181,8 @@ void armada_fbdev_lastclose(struct drm_device *dev)
{
struct armada_private *priv = dev->dev_private;
- drm_modeset_lock_all(dev);
if (priv->fbdev)
- drm_fb_helper_restore_fbdev_mode(priv->fbdev);
- drm_modeset_unlock_all(dev);
+ drm_fb_helper_restore_fbdev_mode_unlocked(priv->fbdev);
}
void armada_fbdev_fini(struct drm_device *dev)
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
b/drivers/gpu/drm/drm_fb_cma_helper.c
index 61b5a47..f27c883 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -429,13 +429,8 @@ EXPORT_SYMBOL_GPL(drm_fbdev_cma_fini);
*/
void drm_fbdev_cma_restore_mode(struct drm_fbdev_cma *fbdev_cma)
{
- if (fbdev_cma) {
- struct drm_device *dev = fbdev_cma->fb_helper.dev;
-
- drm_modeset_lock_all(dev);
- drm_fb_helper_restore_fbdev_mode(&fbdev_cma->fb_helper);
- drm_modeset_unlock_all(dev);
- }
+ if (fbdev_cma)
+
drm_fb_helper_restore_fbdev_mode_unlocked(&fbdev_cma->fb_helper);
}
EXPORT_SYMBOL_GPL(drm_fbdev_cma_restore_mode);
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 43329ce..d5d8cea 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -273,15 +273,7 @@ int drm_fb_helper_debug_leave(struct fb_info *info)
}
EXPORT_SYMBOL(drm_fb_helper_debug_leave);
-/**
- * drm_fb_helper_restore_fbdev_mode - restore fbdev configuration
- * @fb_helper: fbcon to restore
- *
- * This should be called from driver's drm ->lastclose callback
- * when implementing an fbcon on top of kms using this helper. This ensures
that
- * the user isn't greeted with a black screen when e.g. X dies.
- */
-bool drm_fb_helper_restore_fbdev_mode(struct drm_fb_helper *fb_helper)
+static bool restore_fbdev_mode(struct drm_fb_helper *fb_helper)
{
struct drm_device *dev = fb_helper->dev;
struct drm_plane *plane;
@@ -311,7 +303,40 @@ bool drm_fb_helper_restore_fbdev_mode(struct drm_fb_helper
*fb_helper)
}
return error;
}
-EXPORT_SYMBOL(drm_fb_helper_restore_fbdev_mode);
+/**
+ * drm_fb_helper_restore_fbdev_mode - restore fbdev configuration
+ * @fb_helper: fbcon to restore
+ *
+ * This should be called from driver's drm ->lastclose callback
+ * when implementing an fbcon on top of kms using this helper. This ensures
that
+ * the user isn't greeted with a black screen when e.g. X dies.
+ *
+ * Use this variant if you need to bypass locking (panic), or already
+ * hold all modeset locks. Otherwise use
drm_fb_helper_restore_fbdev_mode_unlocked()
+ */
+static bool drm_fb_helper_restore_fbdev_mode(struct drm_fb_helper *fb_helper)
+{
+ return restore_fbdev_mode(fb_helper);
+}
+
+/**
+ * drm_fb_helper_restore_fbdev_mode_unlocked - restore fbdev configuration
+ * @fb_helper: fbcon to restore
+ *
+ * This should be called from driver's drm ->lastclose callback
+ * when implementing an fbcon on top of kms using this helper. This ensures
that
+ * the user isn't greeted with a black screen when e.g. X dies.
+ */
+bool drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper *fb_helper)
+{
+ struct drm_device *dev = fb_helper->dev;
+ bool ret;
+ drm_modeset_lock_all(dev);
+ ret = restore_fbdev_mode(fb_helper);
+ drm_modeset_unlock_all(dev);
+ return ret;
+}
+EXPORT_SYMBOL(drm_fb_helper_restore_fbdev_mode_unlocked);
/*
* restore fbcon display for all kms driver's using this helper, used for sysrq
@@ -824,7 +849,6 @@ EXPORT_SYMBOL(drm_fb_helper_check_var);
int drm_fb_helper_set_par(struct fb_info *info)
{
struct drm_fb_helper *fb_helper = info->par;
- struct drm_device *dev = fb_helper->dev;
struct fb_var_screeninfo *var = &info->var;
if (var->pixclock != 0) {
@@ -832,9 +856,7 @@ int drm_fb_helper_set_par(struct fb_info *info)
[PATCH 1/2] drm: convert crtc and connection_mutex to ww_mutex (v4)
For atomic, it will be quite necessary to not need to care so much
about locking order. And 'state' gives us a convenient place to stash a
ww_ctx for any sort of update that needs to grab multiple crtc locks.
Because we will want to eventually make locking even more fine grained
(giving locks to planes, connectors, etc), split out drm_modeset_lock
and drm_modeset_acquire_ctx to track acquired locks.
Atomic will use this to keep track of which locks have been acquired
in a transaction.
v1: original
v2: remove a few things not needed until atomic, for now
v3: update for v3 of connection_mutex patch..
v4: squash in docbook
Signed-off-by: Rob Clark
---
Documentation/DocBook/drm.tmpl| 6 +
drivers/gpu/drm/Makefile | 3 +-
drivers/gpu/drm/drm_crtc.c| 85 +---
drivers/gpu/drm/drm_crtc_helper.c | 3 +-
drivers/gpu/drm/drm_fb_helper.c | 4 +
drivers/gpu/drm/drm_modeset_lock.c| 247 ++
drivers/gpu/drm/drm_plane_helper.c| 2 +-
drivers/gpu/drm/i915/intel_crt.c | 5 +-
drivers/gpu/drm/i915/intel_display.c | 56 +---
drivers/gpu/drm/i915/intel_dp.c | 14 +-
drivers/gpu/drm/i915/intel_drv.h | 6 +-
drivers/gpu/drm/i915/intel_opregion.c | 4 +-
drivers/gpu/drm/i915/intel_overlay.c | 4 +-
drivers/gpu/drm/i915/intel_panel.c| 8 +-
drivers/gpu/drm/i915/intel_sprite.c | 2 +-
drivers/gpu/drm/i915/intel_tv.c | 5 +-
drivers/gpu/drm/omapdrm/omap_crtc.c | 10 +-
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 8 +-
include/drm/drmP.h| 5 -
include/drm/drm_crtc.h| 15 ++-
include/drm/drm_modeset_lock.h| 123 +
21 files changed, 528 insertions(+), 87 deletions(-)
create mode 100644 drivers/gpu/drm/drm_modeset_lock.c
create mode 100644 include/drm/drm_modeset_lock.h
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 00f1c25..efef637 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -1791,6 +1791,12 @@ void intel_crt_init(struct drm_device *dev)
KMS API Functions
!Edrivers/gpu/drm/drm_crtc.c
+
+ KMS Locking
+!Pdrivers/gpu/drm/drm_modeset_lock.c kms locking
+!Iinclude/drm/drm_modeset_lock.h
+!Edrivers/gpu/drm/drm_modeset_lock.c
+
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 863db84..dd2ba42 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -13,7 +13,8 @@ drm-y :=drm_auth.o drm_buffer.o drm_bufs.o
drm_cache.o \
drm_crtc.o drm_modes.o drm_edid.o \
drm_info.o drm_debugfs.o drm_encoder_slave.o \
drm_trace_points.o drm_global.o drm_prime.o \
- drm_rect.o drm_vma_manager.o drm_flip_work.o
+ drm_rect.o drm_vma_manager.o drm_flip_work.o \
+ drm_modeset_lock.o
drm-$(CONFIG_COMPAT) += drm_ioc32.o
drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index f3b98d4..43735f3 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include "drm_crtc_internal.h"
@@ -50,14 +51,42 @@
*/
void drm_modeset_lock_all(struct drm_device *dev)
{
- struct drm_crtc *crtc;
+ struct drm_mode_config *config = &dev->mode_config;
+ struct drm_modeset_acquire_ctx *ctx;
+ int ret;
- mutex_lock(&dev->mode_config.mutex);
+ ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
+ if (WARN_ON(!ctx))
+ return;
- mutex_lock(&dev->mode_config.connection_mutex);
+ mutex_lock(&config->mutex);
- list_for_each_entry(crtc, &dev->mode_config.crtc_list, head)
- mutex_lock_nest_lock(&crtc->mutex, &dev->mode_config.mutex);
+ drm_modeset_acquire_init(ctx, 0);
+
+retry:
+ ret = drm_modeset_lock(&config->connection_mutex, ctx);
+ if (ret)
+ goto fail;
+ ret = drm_modeset_lock_all_crtcs(dev, ctx);
+ if (ret)
+ goto fail;
+
+ WARN_ON(config->acquire_ctx);
+
+ /* now we hold the locks, so now that it is safe, stash the
+* ctx for drm_modeset_unlock_all():
+*/
+ config->acquire_ctx = ctx;
+
+ drm_warn_on_modeset_not_all_locked(dev);
+
+ return;
+
+fail:
+ if (ret == -EDEADLK) {
+ drm_modeset_backoff(ctx);
+ goto retry;
+ }
}
EXPORT_SYMBOL(drm_modeset_lock_all);
@@ -69,12 +98,17 @@ EXPORT_SYMBOL(drm_modeset_lock_all);
*/
void drm_modeset_unlock_all(struct drm_device *dev)
{
- struct drm_crtc *crtc;
+ struct drm_mode_config *config = &dev->mode_config;
+ struct drm_modeset_acquire_ctx *ctx = config->acquire_ctx;
- list_for_each_entry(crtc, &dev->mode_config.crtc_list, head)
- mutex_unlock(&crtc->mutex)
[PATCH 0/2] remaining bits of 'prepare for preparing for atomic'
The remaining bits.. mostly addition of docs for drm_modeset_lock Rob Clark (2): drm: convert crtc and connection_mutex to ww_mutex (v4) drm: add drm_fb_helper_restore_fbdev_mode_unlocked() Documentation/DocBook/drm.tmpl| 6 + drivers/gpu/drm/Makefile | 3 +- drivers/gpu/drm/armada/armada_fbdev.c | 4 +- drivers/gpu/drm/drm_crtc.c| 85 +++--- drivers/gpu/drm/drm_crtc_helper.c | 3 +- drivers/gpu/drm/drm_fb_cma_helper.c | 9 +- drivers/gpu/drm/drm_fb_helper.c | 54 +-- drivers/gpu/drm/drm_modeset_lock.c| 247 ++ drivers/gpu/drm/drm_plane_helper.c| 2 +- drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 4 +- drivers/gpu/drm/gma500/psb_drv.c | 4 +- drivers/gpu/drm/i915/intel_crt.c | 5 +- drivers/gpu/drm/i915/intel_display.c | 56 --- drivers/gpu/drm/i915/intel_dp.c | 14 +- drivers/gpu/drm/i915/intel_drv.h | 6 +- drivers/gpu/drm/i915/intel_fbdev.c| 6 +- drivers/gpu/drm/i915/intel_opregion.c | 4 +- drivers/gpu/drm/i915/intel_overlay.c | 4 +- drivers/gpu/drm/i915/intel_panel.c| 8 +- drivers/gpu/drm/i915/intel_sprite.c | 2 +- drivers/gpu/drm/i915/intel_tv.c | 5 +- drivers/gpu/drm/msm/msm_drv.c | 7 +- drivers/gpu/drm/omapdrm/omap_crtc.c | 10 +- drivers/gpu/drm/omapdrm/omap_drv.c| 4 +- drivers/gpu/drm/tegra/fb.c| 7 +- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 8 +- include/drm/drmP.h| 5 - include/drm/drm_crtc.h| 15 +- include/drm/drm_fb_helper.h | 2 +- include/drm/drm_modeset_lock.h| 123 +++ 30 files changed, 576 insertions(+), 136 deletions(-) create mode 100644 drivers/gpu/drm/drm_modeset_lock.c create mode 100644 include/drm/drm_modeset_lock.h -- 1.9.3
[PATCH 1/3] drm/radeon: stop poisoning the GART TLB
On Wed, Jun 4, 2014 at 9:29 AM, Christian K?nig wrote: > From: Christian K?nig > > When we set the valid bit on invalid GART entries they are > loaded into the TLB when an adjacent entry is loaded. This > poisons the TLB with invalid entries which are sometimes > not correctly removed on TLB flush. > > For stable inclusion the patch probably needs to be modified a bit. > > Signed-off-by: Christian K?nig > Cc: stable at vger.kernel.org Series is: Reviewed-by: Alex Deucher stable cc on patch 2 or 3 as well? I suppose we'd need to modify the patches anyway so that they would apply on older kernels anyway. Alex > --- > drivers/gpu/drm/radeon/rs600.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/radeon/rs600.c b/drivers/gpu/drm/radeon/rs600.c > index 0a8be63..e0465b2 100644 > --- a/drivers/gpu/drm/radeon/rs600.c > +++ b/drivers/gpu/drm/radeon/rs600.c > @@ -634,7 +634,10 @@ int rs600_gart_set_page(struct radeon_device *rdev, int > i, uint64_t addr) > return -EINVAL; > } > addr = addr & 0xF000ULL; > - addr |= R600_PTE_GART; > + if (addr == rdev->dummy_page.addr) > + addr |= R600_PTE_SYSTEM | R600_PTE_SNOOPED; > + else > + addr |= R600_PTE_GART; > writeq(addr, ptr + (i * 8)); > return 0; > } > -- > 1.9.1 >
[PATCH 1/4] drm/radeon: rename alt_domain to allowed_domains
On Wed, Jun 4, 2014 at 7:00 AM, Christian K?nig
wrote:
> Am 02.06.2014 17:52, schrieb Alex Deucher:
>
>> On Mon, Jun 2, 2014 at 11:33 AM, Christian K?nig
>> wrote:
>>>
>>> From: Christian K?nig
>>>
>>> And also domain to prefered_domains. That matches better
>>> what those values represent.
>>>
>>> Signed-off-by: Christian K?nig
>>> Cc: Marek Ol??k
>>
>> A couple of comments on 2/4, but other than that, the series is:
>>
>> Reviewed-by: Alex Deucher
>
>
> It looks like your comments on #4 never made it to me, could you resend
> them?
>
My comments were only on patch 2 of 4, not patch 4 itself.
Alex
> Thanks,
> Christian.
>
>
>>
>>> ---
>>> drivers/gpu/drm/radeon/radeon.h| 4 ++--
>>> drivers/gpu/drm/radeon/radeon_cs.c | 8
>>> drivers/gpu/drm/radeon/radeon_object.c | 9 +
>>> drivers/gpu/drm/radeon/radeon_vm.c | 8
>>> 4 files changed, 15 insertions(+), 14 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/radeon/radeon.h
>>> b/drivers/gpu/drm/radeon/radeon.h
>>> index 7501ba31..babb7f1 100644
>>> --- a/drivers/gpu/drm/radeon/radeon.h
>>> +++ b/drivers/gpu/drm/radeon/radeon.h
>>> @@ -997,8 +997,8 @@ struct radeon_cs_reloc {
>>> struct radeon_bo*robj;
>>> struct ttm_validate_buffer tv;
>>> uint64_tgpu_offset;
>>> - unsigneddomain;
>>> - unsignedalt_domain;
>>> + unsignedprefered_domains;
>>> + unsignedallowed_domains;
>>> uint32_ttiling_flags;
>>> uint32_thandle;
>>> };
>>> diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
>>> b/drivers/gpu/drm/radeon/radeon_cs.c
>>> index 41ecf8a..71a1434 100644
>>> --- a/drivers/gpu/drm/radeon/radeon_cs.c
>>> +++ b/drivers/gpu/drm/radeon/radeon_cs.c
>>> @@ -140,10 +140,10 @@ static int radeon_cs_parser_relocs(struct
>>> radeon_cs_parser *p)
>>> if (p->ring == R600_RING_TYPE_UVD_INDEX &&
>>> (i == 0 || drm_pci_device_is_agp(p->rdev->ddev))) {
>>> /* TODO: is this still needed for NI+ ? */
>>> - p->relocs[i].domain =
>>> + p->relocs[i].prefered_domains =
>>> RADEON_GEM_DOMAIN_VRAM;
>>>
>>> - p->relocs[i].alt_domain =
>>> + p->relocs[i].allowed_domains =
>>> RADEON_GEM_DOMAIN_VRAM;
>>>
>>> /* prioritize this over any other relocation */
>>> @@ -158,10 +158,10 @@ static int radeon_cs_parser_relocs(struct
>>> radeon_cs_parser *p)
>>> return -EINVAL;
>>> }
>>>
>>> - p->relocs[i].domain = domain;
>>> + p->relocs[i].prefered_domains = domain;
>>> if (domain == RADEON_GEM_DOMAIN_VRAM)
>>> domain |= RADEON_GEM_DOMAIN_GTT;
>>> - p->relocs[i].alt_domain = domain;
>>> + p->relocs[i].allowed_domains = domain;
>>> }
>>>
>>> p->relocs[i].tv.bo = &p->relocs[i].robj->tbo;
>>> diff --git a/drivers/gpu/drm/radeon/radeon_object.c
>>> b/drivers/gpu/drm/radeon/radeon_object.c
>>> index 2918087..6c717b2 100644
>>> --- a/drivers/gpu/drm/radeon/radeon_object.c
>>> +++ b/drivers/gpu/drm/radeon/radeon_object.c
>>> @@ -446,7 +446,7 @@ int radeon_bo_list_validate(struct radeon_device
>>> *rdev,
>>> list_for_each_entry(lobj, head, tv.head) {
>>> bo = lobj->robj;
>>> if (!bo->pin_count) {
>>> - u32 domain = lobj->domain;
>>> + u32 domain = lobj->prefered_domains;
>>> u32 current_domain =
>>>
>>> radeon_mem_type_to_domain(bo->tbo.mem.mem_type);
>>>
>>> @@ -458,7 +458,7 @@ int radeon_bo_list_validate(struct radeon_device
>>> *rdev,
>>> * into account. We don't want to disallow
>>> buffer moves
>>> * completely.
>>> */
>>> - if ((lobj->alt_domain & current_domain) != 0 &&
>>> + if ((lobj->allowed_domains & current_domain) != 0
>>> &&
>>> (domain & current_domain) == 0 && /* will be
>>> moved */
>>> bytes_moved > bytes_moved_threshold) {
>>> /* don't move it */
>>> @@ -476,8 +476,9 @@ int radeon_bo_list_validate(struct radeon_device
>>> *rdev,
>>> initial_bytes_moved;
>>>
>>> if (unlikely(r)) {
>>> - if (r != -ERESTARTSYS && domain !=
>>> lobj->alt_domain) {
>>> - domain = lobj-
[Bug 79520] mpv 0.3.10-1 shows no video after mesa and ati-dri update to version 10.2.0rc5-1
https://bugs.freedesktop.org/show_bug.cgi?id=79520 --- Comment #9 from Christian K?nig --- (In reply to comment #8) > (In reply to comment #7) > > Can you get the backtrace of the segmentation fault? > > To get that, I'd normally have to compile mesa with CFLAGS="-g" make. Will > that work here too? Or is there any other way to do it? (Sorry, I'm not a > programmer myself.) Instead of fiddling with the CFLAGS you should probably better use "--enable-debug" for configure. -- 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/20140604/a28896b9/attachment.html>
[Bug 79520] mpv 0.3.10-1 shows no video after mesa and ati-dri update to version 10.2.0rc5-1
https://bugs.freedesktop.org/show_bug.cgi?id=79520 --- Comment #8 from Savyasachee Jha --- (In reply to comment #7) > Can you get the backtrace of the segmentation fault? To get that, I'd normally have to compile mesa with CFLAGS="-g" make. Will that work here too? Or is there any other way to do it? (Sorry, I'm not a programmer myself.) -- 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/20140604/e9b46ff5/attachment.html>
[Bug 79520] mpv 0.3.10-1 shows no video after mesa and ati-dri update to version 10.2.0rc5-1
https://bugs.freedesktop.org/show_bug.cgi?id=79520 --- Comment #7 from Christian K?nig --- (In reply to comment #6) > (In reply to comment #5) > > This is really stange, since the patch you bisected doesn't touch any of the > > VDPAU or OpenGL states in question. > > > > Can you try mesa master as well? > > > > Thanks, > > Christian. > > I just tried it with the latest master. The steps remain the same. The > output was: > > zsh: segmentation fault (core dumped) LD_LIBRARY_PATH="./src/glx" > LIBGL_DRIVERS_PATH="./lib/gallium/" mpv > > The error number was 139. Can you get the backtrace of the segmentation fault? -- 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/20140604/5b04dab9/attachment.html>
[Bug 79520] mpv 0.3.10-1 shows no video after mesa and ati-dri update to version 10.2.0rc5-1
https://bugs.freedesktop.org/show_bug.cgi?id=79520 --- Comment #6 from Savyasachee Jha --- (In reply to comment #5) > This is really stange, since the patch you bisected doesn't touch any of the > VDPAU or OpenGL states in question. > > Can you try mesa master as well? > > Thanks, > Christian. I just tried it with the latest master. The steps remain the same. The output was: zsh: segmentation fault (core dumped) LD_LIBRARY_PATH="./src/glx" LIBGL_DRIVERS_PATH="./lib/gallium/" mpv The error number was 139. -- 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/20140604/e2bc9c56/attachment.html>
[Bug 79520] mpv 0.3.10-1 shows no video after mesa and ati-dri update to version 10.2.0rc5-1
https://bugs.freedesktop.org/show_bug.cgi?id=79520 --- Comment #5 from Christian K?nig --- (In reply to comment #4) > ee978aee94d98fec669002eb5ef7ceb1f46683a9 is the first bad commit > commit ee978aee94d98fec669002eb5ef7ceb1f46683a9 > Author: Christian K?nig > Date: Mon Jul 15 09:16:22 2013 -0600 > > vl: add H264 encoding interface > > Signed-off-by: Christian K?nig > Signed-off-by: Leo Liu This is really stange, since the patch you bisected doesn't touch any of the VDPAU or OpenGL states in question. Can you try mesa master as well? Thanks, Christian. -- 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/20140604/759a6bcb/attachment.html>
[git pull] drm fixes
Hi Linus, all fairly small, radeon stability and a panic path fix. Mostly radeon fixes, suspend/resume fix, stability on the CIK chipsets, along with a locking check avoidance patch for panic times regression. Dave. The following changes since commit 18ee37a485653aa635cfab9a3710e9bcf5fbca01: drm/radeon: Resume fbcon last (2014-05-31 09:19:51 +1000) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to 0a4ae727d6aa459247b027387edb6ff99f657792: Merge branch 'drm-fixes-3.15' of git://people.freedesktop.org/~deathsimple/linux into drm-fixes (2014-06-04 13:29:13 +1000) Alex Deucher (1): drm/radeon/dpm: resume fixes for some systems Christian K?nig (3): drm/radeon: fix vm buffer size estimation drm/radeon: sync page table updates drm/radeon: use the CP DMA on CIK Dave Airlie (1): Merge branch 'drm-fixes-3.15' of git://people.freedesktop.org/~deathsimple/linux into drm-fixes Sergei Antonov (1): drm/crtc-helper: skip locking checks in panicking path drivers/gpu/drm/drm_crtc_helper.c | 17 +++-- drivers/gpu/drm/radeon/atombios_crtc.c | 6 ++ drivers/gpu/drm/radeon/radeon_asic.c | 4 ++-- drivers/gpu/drm/radeon/radeon_device.c | 4 drivers/gpu/drm/radeon/radeon_pm.c | 1 - drivers/gpu/drm/radeon/radeon_vm.c | 11 --- 6 files changed, 31 insertions(+), 12 deletions(-)
[PATCH] drm/i915: Kick out vga console
From: Chris Wilson
Touching the VGA resources on an IVB EFI machine causes hard hangs when
we then kick out the efifb. Ouch.
Apparently this also prevents unclaimed register errors on hsw and
hard machine hangs on my i855gm when trying to unbind fbcon.
Also, we want this to make I915_FBDEV=n safe.
v2: Rebase and pimp commit message.
v3: We also need to unregister the vga console, otherwise the unbind
of the fb console before module unload might resurrect it again.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67813
Cc: David Herrmann
Cc: Jean-Christophe Plagniol-Villard
Cc: Tomi Valkeinen
Cc: linux-fbdev at vger.kernel.org
Signed-off-by: Chris Wilson (v1)
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_dma.c | 34 +-
drivers/video/console/dummycon.c | 1 +
drivers/video/console/vgacon.c | 1 +
3 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index b9159ade5e85..a4df80740b37 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -36,6 +36,8 @@
#include "i915_drv.h"
#include "i915_trace.h"
#include
+#include
+#include
#include
#include
#include
@@ -1450,6 +1452,29 @@ static void i915_kick_out_firmware_fb(struct
drm_i915_private *dev_priv)
}
#endif
+static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
+{
+#if !defined(CONFIG_VGA_CONSOLE)
+ return 0;
+#else
+ int ret;
+
+#if !defined(CONFIG_DUMMY_CONSOLE)
+ return -ENODEV;
+#endif
+
+ DRM_INFO("Replacing VGA console driver\n");
+
+ console_lock();
+ ret = do_take_over_console(&dummy_con, 0, MAX_NR_CONSOLES - 1, 1);
+ if (ret == 0)
+ ret = do_unregister_con_driver(&vga_con);
+ console_unlock();
+
+ return ret;
+#endif
+}
+
static void i915_dump_device_info(struct drm_i915_private *dev_priv)
{
const struct intel_device_info *info = &dev_priv->info;
@@ -1623,8 +1648,15 @@ int i915_driver_load(struct drm_device *dev, unsigned
long flags)
if (ret)
goto out_regs;
- if (drm_core_check_feature(dev, DRIVER_MODESET))
+ if (drm_core_check_feature(dev, DRIVER_MODESET)) {
+ ret = i915_kick_out_vgacon(dev_priv);
+ if (ret) {
+ DRM_ERROR("failed to remove conflicting VGA console\n");
+ goto out_gtt;
+ }
+
i915_kick_out_firmware_fb(dev_priv);
+ }
pci_set_master(dev->pdev);
diff --git a/drivers/video/console/dummycon.c b/drivers/video/console/dummycon.c
index b63860f7beab..40bec8d64b0a 100644
--- a/drivers/video/console/dummycon.c
+++ b/drivers/video/console/dummycon.c
@@ -77,3 +77,4 @@ const struct consw dummy_con = {
.con_set_palette = DUMMY,
.con_scrolldelta = DUMMY,
};
+EXPORT_SYMBOL_GPL(dummy_con);
diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c
index 9d8feac67637..84acd6223dc5 100644
--- a/drivers/video/console/vgacon.c
+++ b/drivers/video/console/vgacon.c
@@ -1440,5 +1440,6 @@ const struct consw vga_con = {
.con_build_attr = vgacon_build_attr,
.con_invert_region = vgacon_invert_region,
};
+EXPORT_SYMBOL(vga_con);
MODULE_LICENSE("GPL");
--
1.8.1.4
[Bug 79520] mpv 0.3.10-1 shows no video after mesa and ati-dri update to version 10.2.0rc5-1
https://bugs.freedesktop.org/show_bug.cgi?id=79520 Michel D?nzer changed: What|Removed |Added CC||deathsimple at vodafone.de Component|Drivers/DRI/R100|Drivers/Gallium/r600 -- 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/20140604/222947d5/attachment.html>
