dri-devel March 2014

dri-devel@lists.freedesktop.org

144 participants
926 discussions

[drm] WARNING: CPU: 0 PID: 0 at kernel/locking/mutex.c:516 mutex_lock_nested()
by Fengguang Wu 07 Mar '14

07 Mar '14

Hi David, I got the below dmesg and the first bad commit is git://people.freedesktop.org/~dvdhrm/linux drm-log commit 06bdc9aa3cd3a045b4a94bdc4c6c582338cf7992 Author: David Herrmann <dh.herrmann(a)gmail.com> AuthorDate: Wed Mar 5 17:34:49 2014 +0100 Commit: David Herrmann <dh.herrmann(a)gmail.com> CommitDate: Fri Mar 7 11:50:20 2014 +0100 drm: add kernel-log renderer +-----------------------------------------------------------------------------+------------+------… [View More]------+------------+ | | 32afb1337b | 06bdc9aa3c | 05ffd9cb67 | +-----------------------------------------------------------------------------+------------+------------+------------+ | boot_successes | 56 | 0 | 0 | | boot_failures | 4 | 20 | 19 | | BUG:unable_to_handle_kernel_NULL_pointer_dereference | 1 | | | | Oops:SMP | 1 | | | | EIP_is_at_reset_interrupt | 1 | | | | Kernel_panic-not_syncing:Fatal_exception | 1 | | | | WARNING:CPU:PID:at_arch/x86/kernel/cpu/amd.c:init_amd() | 3 | 0 | 2 | | backtrace:init_amd | 3 | 0 | 2 | | backtrace:warn_slowpath_fmt | 3 | 0 | 2 | | WARNING:CPU:PID:at_kernel/locking/mutex.c:mutex_lock_nested() | 0 | 7 | 8 | | BUG:sleeping_function_called_from_invalid_context_at_kernel/locking/mutex.c | 0 | 20 | 19 | | INFO:lockdep_is_turned_off | 0 | 7 | 10 | | backtrace:ring_buffer_consumer_thread | 0 | 2 | 1 | | backtrace:vfs_read | 0 | 15 | 13 | | backtrace:SyS_read | 0 | 15 | 13 | | backtrace:cpu_startup_entry | 0 | 5 | 6 | | backtrace:serio_handle_event | 0 | 5 | 6 | | backtrace:ring_buffer_producer_thread | 0 | 0 | 1 | | backtrace:do_group_exit | 0 | 0 | 1 | | backtrace:SyS_exit_group | 0 | 0 | 1 | +-----------------------------------------------------------------------------+------------+------------+------------+ [ 12.906820] ... PIC ELCR: 0c00 [ 12.909878] printing local APIC contents on CPU#0/0: [ 12.910508] ------------[ cut here ]------------ [ 12.910521] WARNING: CPU: 0 PID: 0 at kernel/locking/mutex.c:516 mutex_lock_nested+0xc7/0x430() [ 12.910523] DEBUG_LOCKS_WARN_ON(in_interrupt()) [ 12.910524] Modules linked in: [ 12.910532] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.14.0-rc5-00558-g05ffd9c #230 [ 12.910539] 00000000 00000000 79c05d64 798860ec 79c05da4 79c05d94 790414ee 79b1a074 [ 12.910544] 79c05dc0 00000000 79b1fbf8 00000204 79892017 79892017 79c499a0 00000001 [ 12.910549] 79c096e0 79c05dac 79041543 00000009 79c05da4 79b1a074 79c05dc0 79c05e08 [ 12.910550] Call Trace: [ 12.910557] [<798860ec>] dump_stack+0x48/0x60 [ 12.910566] [<790414ee>] warn_slowpath_common+0x7e/0xa0 [ 12.910570] [<79892017>] ? mutex_lock_nested+0xc7/0x430 [ 12.910572] [<79892017>] ? mutex_lock_nested+0xc7/0x430 [ 12.910577] [<79041543>] warn_slowpath_fmt+0x33/0x40 [ 12.910579] [<79892017>] mutex_lock_nested+0xc7/0x430 [ 12.910592] [<7939d718>] ? io_serial_in+0x8/0x20 [ 12.910595] [<7939e3a2>] ? wait_for_xmitr+0x22/0x90 [ 12.910606] [<793d7744>] ? drm_log_write+0xb4/0xe0 [ 12.910613] [<79093ac2>] ? do_raw_spin_unlock+0xb2/0xe0 [ 12.910616] [<793d7700>] ? drm_log_write+0x70/0xe0 [ 12.910618] [<793d7744>] drm_log_write+0xb4/0xe0 [ 12.910621] [<7939e50a>] ? serial8250_console_write+0xfa/0x120 [ 12.910623] [<7939e530>] ? serial8250_console_write+0x120/0x120 [ 12.910627] [<793d7783>] dlog_con_write+0x13/0x20 [ 12.910630] [<79097a53>] call_console_drivers.constprop.8+0x133/0x1b0 [ 12.910633] [<79098018>] console_unlock+0x328/0x4c0 [ 12.910637] [<790987fa>] vprintk_emit+0x64a/0x680 [ 12.910640] [<79882730>] printk+0x3d/0x3f [ 12.910658] [<79d02f26>] print_local_APIC+0x29/0x3e6 [ 12.910664] [<790b8510>] generic_smp_call_function_single_interrupt+0xe0/0x230 [ 12.910668] [<7902aa35>] smp_call_function_single_interrupt+0x25/0x40 [ 12.910672] [<798966da>] call_function_single_interrupt+0x32/0x38 [ 12.910677] [<790368e5>] ? native_safe_halt+0x5/0x10 [ 12.910682] [<7900afa3>] default_idle+0x63/0x110 [ 12.910685] [<7900b957>] arch_cpu_idle+0x17/0x40 [ 12.910688] [<79099eae>] cpu_startup_entry+0x20e/0x3c0 [ 12.910693] [<7987d999>] rest_init+0xb9/0xc0 [ 12.910696] [<7987d8e0>] ? reciprocal_value+0x70/0x70 [ 12.910700] [<79cf4aa0>] start_kernel+0x3ba/0x41a [ 12.910703] [<79cf451d>] ? repair_env_string+0x51/0x51 [ 12.910706] [<79cf4358>] i386_start_kernel+0x12e/0x131 [ 12.910714] ---[ end trace bec5db8963544a10 ]--- [ 12.919853] ... APIC ID: 00000000 (0) git bisect start 05ffd9cb67c1bc9a4b4e3007df326e4e6f2d7db0 0414855fdc4a40da05221fc6062cccbc0c30f169 -- git bisect bad d6624f53631bba754e89f4d204c6248ee0d314f1 # 23:17 0- 8 Merge 'dvdhrm/drm-log' into devel-roam-i386-201403072151 git bisect good 5bbe2fa5f7e2c75a85348e0ae4a1cca7d2a0e4a8 # 23:22 20+ 0 0day base guard for 'devel-roam-i386-201403072151' git bisect good b82a37f7f077567a7f744a98040d2e566632e385 # 23:26 20+ 0 Merge 'gfs2/master' into devel-roam-i386-201403072151 git bisect good e81ca8076832ed2197a6bdb05dbc769dad159f7d # 23:34 20+ 2 drm/i915: We implement WaDisableRCCUnitClockGating:snb git bisect good c1874ed7c987664176bd00301f844e91609fe535 # 23:55 20+ 0 drm/i915: factor out valleyview_pipestat_irq_handler git bisect good c48cdd23ea5006c377b670bc3056fa7b63f92574 # 00:28 20+ 0 Merge branch 'tda998x-devel' of git://ftp.arm.linux.org.uk/~rmk/linux-cubox into drm-next git bisect good 4d538b79197901fecc42e746d515d07fd1089b62 # 00:39 20+ 0 Merge branch 'drm-next-3.15' of git://people.freedesktop.org/~deathsimple/linux into drm-next git bisect bad 06bdc9aa3cd3a045b4a94bdc4c6c582338cf7992 # 00:41 0- 1 drm: add kernel-log renderer git bisect good 32afb1337bdffd1df2ac4ae749eace37528c747f # 00:55 20+ 0 lib: remove FBCON dependency for fonts # first bad commit: [06bdc9aa3cd3a045b4a94bdc4c6c582338cf7992] drm: add kernel-log renderer git bisect good 32afb1337bdffd1df2ac4ae749eace37528c747f # 01:06 60+ 4 lib: remove FBCON dependency for fonts git bisect bad 05ffd9cb67c1bc9a4b4e3007df326e4e6f2d7db0 # 01:06 0- 19 0day head guard for 'devel-roam-i386-201403072151' git bisect good 6c0eb6436ff95fbd405fd8ac292626247b1e0f96 # 01:27 60+ 5 Revert "drm: add kernel-log renderer" git bisect good c3bebc71c4bcdafa24b506adf0c1de3c1f77e2e0 # 02:28 60+ 1 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net git bisect good 1b0a7e3263168a06d3858798e48c5a21d1c78d3c # 02:40 60+ 1 Add linux-next specific files for 20140307 Thanks, Fengguang _______________________________________________ LKP mailing list LKP(a)linux.intel.com [View Less]

1 0

[PATCH 1/2] imx-drm: imx-ldb: Add drm_panel support
by Philipp Zabel 07 Mar '14

07 Mar '14

This patch allows to optionally attach the lvds-channel to a panel supported by a drm_panel driver instead of supplying the modes via device tree. Before: ldb { ... lvds-channel@0 { ... display-timings { native-timing = <&timing1>; timing1: etm0700g0dh6 { hactive = <800>; vactive = <480>; clock-frequency = <33260000>; hsync-len = <128>; hback-porch = <88>; hfront-porch = <40>; vsync-len = … [View More]<2>; vback-porch = <33>; vfront-porch = <10>; hsync-active = <0>; vsync-active = <0>; ... }; }; ... }; }; After: ldb { ... lvds-channel@0 { fsl,panel = <&panel>; ... }; }; panel: panel { compatible = "edt,etm0700g0dh6", "simple-panel"; }; Signed-off-by: Philipp Zabel <p.zabel(a)pengutronix.de> --- drivers/staging/imx-drm/imx-ldb.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/drivers/staging/imx-drm/imx-ldb.c b/drivers/staging/imx-drm/imx-ldb.c index 4576830..38a0795 100644 --- a/drivers/staging/imx-drm/imx-ldb.c +++ b/drivers/staging/imx-drm/imx-ldb.c @@ -24,6 +24,7 @@ #include <drm/drmP.h> #include <drm/drm_fb_helper.h> #include <drm/drm_crtc_helper.h> +#include <drm/drm_panel.h> #include <linux/mfd/syscon.h> #include <linux/mfd/syscon/imx6q-iomuxc-gpr.h> #include <linux/of_address.h> @@ -60,6 +61,7 @@ struct imx_ldb_channel { struct imx_ldb *ldb; struct drm_connector connector; struct drm_encoder encoder; + struct drm_panel *panel; struct device_node *child; int chno; void *edid; @@ -96,6 +98,13 @@ static int imx_ldb_connector_get_modes(struct drm_connector *connector) struct imx_ldb_channel *imx_ldb_ch = con_to_imx_ldb_ch(connector); int num_modes = 0; + if (imx_ldb_ch->panel && imx_ldb_ch->panel->funcs && + imx_ldb_ch->panel->funcs->get_modes) { + num_modes = imx_ldb_ch->panel->funcs->get_modes(imx_ldb_ch->panel); + if (num_modes > 0) + return num_modes; + } + if (imx_ldb_ch->edid) { drm_mode_connector_update_edid_property(connector, imx_ldb_ch->edid); @@ -240,6 +249,8 @@ static void imx_ldb_encoder_commit(struct drm_encoder *encoder) } regmap_write(ldb->regmap, IOMUXC_GPR2, ldb->ldb_ctrl); + + drm_panel_enable(imx_ldb_ch->panel); } static void imx_ldb_encoder_mode_set(struct drm_encoder *encoder, @@ -291,6 +302,8 @@ static void imx_ldb_encoder_disable(struct drm_encoder *encoder) (ldb->ldb_ctrl & LDB_CH1_MODE_EN_MASK) == 0) return; + drm_panel_disable(imx_ldb_ch->panel); + if (imx_ldb_ch == &ldb->channel[0]) ldb->ldb_ctrl &= ~LDB_CH0_MODE_EN_MASK; else if (imx_ldb_ch == &ldb->channel[1]) @@ -376,6 +389,9 @@ static int imx_ldb_register(struct drm_device *drm, drm_connector_init(drm, &imx_ldb_ch->connector, &imx_ldb_connector_funcs, DRM_MODE_CONNECTOR_LVDS); + if (imx_ldb_ch->panel) + drm_panel_attach(imx_ldb_ch->panel, &imx_ldb_ch->connector); + drm_mode_connector_attach_encoder(&imx_ldb_ch->connector, &imx_ldb_ch->encoder); @@ -490,6 +506,7 @@ static int imx_ldb_bind(struct device *dev, struct device *master, void *data) for_each_child_of_node(np, child) { struct imx_ldb_channel *channel; + struct device_node *panel_node; ret = of_property_read_u32(child, "reg", &i); if (ret || i < 0 || i > 1) @@ -549,6 +566,10 @@ static int imx_ldb_bind(struct device *dev, struct device *master, void *data) return -EINVAL; } + panel_node = of_parse_phandle(child, "fsl,panel", 0); + if (panel_node) + channel->panel = of_drm_find_panel(panel_node); + ret = imx_ldb_register(drm, channel); if (ret) return ret; -- 1.9.0 [View Less]

2 5

Re: Request for feedback : [RFC] Added a new 'window size' property for connector
by Ville Syrjälä 07 Mar '14

07 Mar '14

[ccing dri-devel so other people can see what we're cooking...] On Fri, Mar 07, 2014 at 01:49:18PM +0000, Goel, Akash wrote: > > In my ideal solution the panel fitter output will be hdisplay/vdisplay > > +/- the border (depending on which way we define it), and the panel > > +fitter > > input size will be defined as a new crtc property. > > Please could you kindly clarify, so as to avoid any ambiguity/confusion on our side, that by 'hdisplay/vdisplay', are you … [View More]referring to values programmed in PIPESRC or 'HACTIVE/VACTIVE' (pipe timings) ? > As per our understanding that border info shall be applied on the 'HACTIVE/VACTIVE', i.e. (HACTIVE - Left border - Right Border) x (VACTIVE - Top Border - Bottom border) will be the output rectangle on screen. I mean what's there in the mode structure. So if we define the border as something that reduces hactive/vactice, we'd program the pfit output size as hactive-left_border-right_border x vactive-top_border-bottom_border. > > Please also confirm for the border info, you prefer a new property or an update of the 'drm_mode_modeinfo' structure ? We can't change the already existing structure, so if we want to update it we'd need drm_mode_modeinfo2 or something and a new set ioctls. My sense of aestethics would prefer that, but from a practical point of view properties seem like the easier choice. > If the panel fitter input size is defined as a new crtc property, then once User modifies the input size through this property, PIPESRC shall also be updated with it at that time. But actually change in PIPESRC programming alone, could also require a reprogramming of the Panel fitter in some cases. Yeah. Before the atomic modeset API is introduced, userspace might want to first disable the crtc, then change the properties, and then set a new mode. That would make it appear atomic and it can avoid problems where the intermediate state isn't exactly valid. > > Best Regards > Akash > > -----Original Message----- > From: Ville Syrjälä [mailto:ville.syrjala@linux.intel.com] > Sent: Friday, March 07, 2014 6:31 PM > To: Goel, Akash > Cc: Chris Wilson; intel-gfx(a)lists.freedesktop.org; G, Pallavi; Purushothaman, Vijay A > Subject: Re: Request for feedback : [RFC] Added a new 'window size' property for connector > > On Fri, Mar 07, 2014 at 12:45:26PM +0000, Goel, Akash wrote: > > Thanks for your feedback. > > > > > No, fb_id is passed through setcrtc (or soon through setplane, I hope). > > Actually mentioned 'fb_id' also, because if PIPESRC programming is also being updated (as Panel fitter input), then the 'fb' already attached to 'crtc' may not be aligned with it. So there could be a momentary corruption caused when internal modeset is done by Driver (to change the Panel fitter setting), which will last till the next page flip (or setplane). > > > > > > No, we need both the border and the PIPESRC information. hdisplay/vdisplays isn't enough since the user facing mode structure doesn't have vblank_start/end fields. Hence we can't specify borders. > > > If we don't want to extend the display mode, we should add border > > > properties of some sort. I know some drivers have added something like that to the connectors, but again since the mode is applied to the crtc, ideally these properties should also be on the crtc. > > > > Sorry but it's not quite clear. This is what is my understanding so far, please kindly correct wherever wrong. > > > > 1. We need border info for the output of Panel fitter, which will determine the display window. Using the border info we will manipulate the hblank/vblank start/end fields. > > 2. Currently the values of 'hdisplay/vdisplay' fields sent in 'drm_mode_modeinfo' structure gets programmed in PIPESRC. So if we are adding border info to the same structure, then we can use the 'hdisplay/vdisplay' fields only for > > PIPESRC. But if we are defining a new property, to convey the border info, then we need the PIPESRC information also along with it. > > > > Please confirm that should we add a new a 'blob' type property for 'crtc' ? > > In my ideal solution the panel fitter output will be hdisplay/vdisplay > +/- the border (depending on which way we define it), and the panel > +fitter > input size will be defined as a new crtc property. > > -- > Ville Syrjälä > Intel OTC -- Ville Syrjälä Intel OTC [View Less]

2 1

[Bug 75223] New: 3840x2160 HDMI 30Hz fails on XFX r7-240a-clh4 and r7-250a-lzh4
by bugzilla-daemon＠freedesktop.org 07 Mar '14

07 Mar '14

https://bugs.freedesktop.org/show_bug.cgi?id=75223 Priority: medium Bug ID: 75223 Assignee: dri-devel(a)lists.freedesktop.org Summary: 3840x2160 HDMI 30Hz fails on XFX r7-240a-clh4 and r7-250a-lzh4 Severity: normal Classification: Unclassified OS: Linux (All) Reporter: adam_richter2004(a)yahoo.com Hardware: x86 (IA32) Status: NEW Version: XOrg CVS … [View More]

1 4

[PATCH 00/11] SimpleDRM & Sysfb
by David Herrmann 07 Mar '14

07 Mar '14

Hi Another round of SimpleDRM patches. I somehow lost track of the last ones and as this is a major rewrite, I'll just start at v1 again. Some comments up-front: - @Ingo: Patch #1 and #2 are unchanged from the previous ML discussions. I included them in this series as the other patches depend on them. Could you pick them up for the x86 tree? The other 9 patches won't make it in 3.14 so no reason to put them through the DRM tree. All mentioned issues should be addressed. If there'… [View More]s still sth missing, please let me know. - The DRM patches depend on my "DRM Anonymous Inode" patches. But it should be trivial to apply them on drm-next (I think only one line needs to be changed: i_mapping => dev_mapping). - I tested the SimpleDRM fbdev fallback with linux-console+Xorg and it works fine. The DRM backend is only tested with some DRM tests I have locally. I have no idea how to make Xorg pick up a specific /dev/dri/card0 card. It always tells me "no screens found" (as the underlying device is not marked as boot_vga..). If someone knows how to tell Xorg to use card0, I'd gladly test this. But I'm no longer used to writing xorg.confs.. This series introduces two new concepts: sysfb and SimpleDRM Sysfb is just a generalization of the x86-sysfb concept. It allows to register firmware-framebuffers with the system as platform-devices. This way, drivers can properly bind to these devices and we prevent multiple drivers from accessing the same firmware-framebuffer. Sysfb also provides hooks to get a safe handover to real hw-drivers (like i915). Please see the "video: sysfb: add generic firmware-fb interface" patch for a thorough description of the API. This patch also adds a rather verbose documentation of all known firmware-fb facilities. As second part, this series introduces SimpleDRM. It's a very basic DRM driver that can replace efifb, vesafb, simplefb and friends. It's 100% compatible to the "udl" DRM driver, so user-space like xf86-video-modesetting can pick them up just fine. User-space that cannot deal with drmModeDirtyFB() (like weston and friends) currently cannot use SimpleDRM. However, that's also true for all other DRM drivers which provide shadow framebuffers. We could provide something like FB-DEFIO, but that's just useless overhead to paper of lazy user-space. I have tested this with all hardware that I have at home, with a lot hand-over combinations (with/without SYSFB, with efifb/vesafb/simplefb, with SimpleDRM, ...) and all worked great so far. Comments welcome! David David Herrmann (11): x86: sysfb: fool-proof CONFIG_X86_SYSFB x86: sysfb: remove sysfb when probing real hw fbdev: efifb: add dev->remove() callback fbdev: vesafb: add dev->remove() callback x86: sysfb: store apertures in simplefb platform-data video: sysfb: add generic firmware-fb interface drm: mgag200: remove redundant fbdev removal drm/i915: remove sysfbs early drm: add SimpleDRM driver drm: simpledrm: add fbdev fallback support x86/sysfb: allow sysfb+simpledrm combination Documentation/firmware-fbs.txt | 236 +++++++++++++++++ MAINTAINERS | 8 + arch/x86/Kconfig | 2 + arch/x86/include/asm/sysfb.h | 6 +- arch/x86/kernel/sysfb.c | 3 +- arch/x86/kernel/sysfb_simplefb.c | 97 ++++--- drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/i915/i915_drv.c | 6 + drivers/gpu/drm/mgag200/mgag200_main.c | 9 - drivers/gpu/drm/simpledrm/Kconfig | 29 +++ drivers/gpu/drm/simpledrm/Makefile | 4 + drivers/gpu/drm/simpledrm/simpledrm.c | 263 +++++++++++++++++++ drivers/gpu/drm/simpledrm/simpledrm.h | 122 +++++++++ drivers/gpu/drm/simpledrm/simpledrm_damage.c | 306 ++++++++++++++++++++++ drivers/gpu/drm/simpledrm/simpledrm_fbdev.c | 148 +++++++++++ drivers/gpu/drm/simpledrm/simpledrm_gem.c | 282 +++++++++++++++++++++ drivers/gpu/drm/simpledrm/simpledrm_kms.c | 365 +++++++++++++++++++++++++++ drivers/video/Kconfig | 3 + drivers/video/Makefile | 1 + drivers/video/efifb.c | 13 +- drivers/video/fbmem.c | 17 +- drivers/video/simplefb.c | 8 - drivers/video/sysfb.c | 348 +++++++++++++++++++++++++ drivers/video/vesafb.c | 13 +- include/linux/fb.h | 9 +- include/linux/platform_data/simplefb.h | 2 + include/linux/sysfb.h | 62 +++++ 28 files changed, 2299 insertions(+), 66 deletions(-) create mode 100644 Documentation/firmware-fbs.txt create mode 100644 drivers/gpu/drm/simpledrm/Kconfig create mode 100644 drivers/gpu/drm/simpledrm/Makefile create mode 100644 drivers/gpu/drm/simpledrm/simpledrm.c create mode 100644 drivers/gpu/drm/simpledrm/simpledrm.h create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_damage.c create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_fbdev.c create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_gem.c create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_kms.c create mode 100644 drivers/video/sysfb.c create mode 100644 include/linux/sysfb.h -- 1.8.5.3 [View Less]

4 28

Re: 915: [drm] stuck on render ring
by Chris Wilson 07 Mar '14

07 Mar '14

On Fri, Mar 07, 2014 at 02:59:23PM +0100, Toralf Förster wrote: > ick, attached full compressed file It's the infamous https://bugs.freedesktop.org/show_bug.cgi?id=54226 -Chris -- Chris Wilson, Intel Open Source Technology Centre

1 0

915: [drm] stuck on render ring
by Toralf Förster 07 Mar '14

07 Mar '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 At a ThinkPad T420 with i915 and kernel 3.12.13 my watchdog scripts told me : Mar 6 18:45:02 n22 kernel: [drm] stuck on render ring Mar 6 18:45:02 n22 kernel: [drm] stuck on blitter ring Mar 6 18:45:02 n22 kernel: [drm] capturing error event; look for more information in /sys/class/drm/card0/error The content of the first 1000 lines of /sys/class/drm/card0/error is attached. - -- MfG/Sincerely Toralf Förster pgp finger print:1A37 6F99 … [View More]

2 1

[PATCH] drm/nouveau/fb: mark ramfuc_reg() noinline
by Paul Bolle 07 Mar '14

07 Mar '14

Building ramnve0.o triggers a GCC warning on 32 bits x86: drivers/gpu/drm/nouveau/core/subdev/fb/ramnve0.c: In function 'nve0_ram_ctor': drivers/gpu/drm/nouveau/core/subdev/fb/ramnve0.c:1253:1: warning: the frame size of 1496 bytes is larger than 1024 bytes [-Wframe-larger-than=] This warning is caused by ramfuc_reg(), which is inlined 74 times in nve0_ram_ctor(). Mark it noinline to silence this warning. Signed-off-by: Paul Bolle <pebolle(a)tiscali.nl> --- Compile tested (on 32 … [View More]

1 1

nouveau crash due to missing channel (WAS: Re: [ANNOUNCE] 3.12.12-rt19)
by Sebastian Andrzej Siewior 07 Mar '14

07 Mar '14

* Fernando Lopez-Lezcano | 2014-03-01 17:48:29 [-0800]: >On 02/23/2014 10:47 AM, Sebastian Andrzej Siewior wrote: >>Dear RT folks! >> >>I'm pleased to announce the v3.12.12-rt19 patch set. > >Just hit this Oops in my desktop at home: > >[22328.388996] BUG: unable to handle kernel NULL pointer dereference >at 0000000000000008 >[22328.389013] IP: [<ffffffffa011a912>] >nouveau_fence_wait_uevent.isra.2+0x22/0x440 [nouveau] This is | static int | … [View More]nouveau_fence_wait_uevent(struct nouveau_fence *fence, bool intr) | | { | struct nouveau_channel *chan = fence->channel; | struct nouveau_fifo *pfifo = nouveau_fifo(chan->drm->device); and chan is NULL. >[22328.389046] RAX: 0000000000000000 RBX: ffff8807a68f8fa8 RCX: >0000000000000000 >[22328.389046] RDX: 0000000000000001 RSI: ffff8807a68f8fb0 RDI: >ffff8807a68f8fa8 >[22328.389047] RBP: ffff8807c09bdca0 R08: 000000000000045e R09: >000000000000e200 >[22328.389047] R10: ffffffffa0157d80 R11: ffff8807c09bdde0 R12: >0000000000000001 >[22328.389047] R13: 0000000000000000 R14: ffff8807d8493a80 R15: >ffff8807a68f8fb0 >[22328.389053] Call Trace: >[22328.389069] [<ffffffffa011af56>] nouveau_fence_wait+0x86/0x1a0 [nouveau] >[22328.389081] [<ffffffffa011ca35>] nouveau_bo_fence_wait+0x15/0x20 >[nouveau] >[22328.389084] [<ffffffffa00867c6>] ttm_bo_wait+0x96/0x1a0 [ttm] >[22328.389095] [<ffffffffa0121dac>] >nouveau_gem_ioctl_cpu_prep+0x5c/0xf0 [nouveau] >[22328.389101] [<ffffffffa002cd42>] drm_ioctl+0x502/0x630 [drm] >[22328.389114] [<ffffffffa01180a1>] nouveau_drm_ioctl+0x51/0x90 [nouveau] I can't find any kind of locking so my question is what ensures that chan is not set to NULL between nouveau_fence_done() and nouveau_fence_wait_uevent()? There are just a few opcodes in between but nothing that pauses nouveau_fence_signal(). Fernando, can you please check the patch below and test if the warning or the crash appears? diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c b/drivers/gpu/drm/nouveau/nouveau_fence.c --- a/drivers/gpu/drm/nouveau/nouveau_fence.c +++ b/drivers/gpu/drm/nouveau/nouveau_fence.c @@ -184,14 +184,20 @@ nouveau_fence_wait_uevent(struct nouveau_fence *fence, bool intr) { struct nouveau_channel *chan = fence->channel; - struct nouveau_fifo *pfifo = nouveau_fifo(chan->drm->device); - struct nouveau_fence_priv *priv = chan->drm->fence; + struct nouveau_fifo *pfifo; + struct nouveau_fence_priv *priv; struct nouveau_fence_uevent uevent = { .handler.func = nouveau_fence_wait_uevent_handler, - .priv = priv, }; int ret = 0; + if (WARN_ON_ONCE(!chan)) + return 0; + + pfifo = nouveau_fifo(chan->drm->device); + priv = chan->drm->fence; + uevent.priv = priv; + nouveau_event_get(pfifo->uevent, 0, &uevent.handler); if (fence->timeout) { >-- Fernando Sebastian [View Less]

2 2

[git pull] drm fixes
by Dave Airlie 07 Mar '14

07 Mar '14

Hi Linus, mostly intel and radeon fixes, one tda998x, one kconfig dep fix and two more MAINTAINERS updates, All pretty run of the mill for this stage, Dave. The following changes since commit 0414855fdc4a40da05221fc6062cccbc0c30f169: Linux 3.14-rc5 (2014-03-02 18:56:16 -0800) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to 45db98e54242f3ae94bdcfbfe754e743252eb168: Merge branch 'drm-fixes-3.14' of git://… [View More]people.freedesktop.org/~agd5f/linux into drm-fixes (2014-03-07 09:27:22 +1000) ---------------------------------------------------------------- Akash Goel (1): drm/i915: Resolving the memory region conflict for Stolen area Alex Deucher (4): drm/radeon: resume old pm late drm/radeon/cik: fix typo in documentation drm/radeon/dpm: fix typo in EVERGREEN_SMC_FIRMWARE_HEADER_softRegisters drm/radeon/atom: select the proper number of lanes in transmitter setup Dave Airlie (5): MAINTAINERS: update AGP tree to point at drm tree Merge tag 'drm-intel-fixes-2014-03-04' of ssh://git.freedesktop.org/git/drm-intel into drm-fixes Merge branch 'drm-fixes-3.14' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Merge branch 'drm-armada-fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-cubox into drm-fixes Merge branch 'drm-fixes-3.14' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Gerd Hoffmann (1): drm: fix bochs kconfig dependencies Imre Deak (2): drm/i915: fix pch pci device enumeration drm/i915: vlv: reserve GT power context early Jani Nikula (1): drm/i915: use backlight legacy combination mode also for i915gm/i945gm Lauri Kasanen (1): drm/radeon: TTM must be init with cpu-visible VRAM, v2 Paul Bolle (1): drm/radeon: silence GCC warning on 32 bit Paulo Zanoni (1): drm/i915: fix assert_cursor on BDW Russell King (2): DRM: armada: fix use of kfifo_put() MAINTAINERS: add maintainer entry for TDA998x driver Ville Syrjälä (1): drm/i915: Reject >165MHz modes w/ DVI monitors MAINTAINERS | 8 +++++++- drivers/gpu/drm/armada/armada_drv.c | 10 +--------- drivers/gpu/drm/bochs/Kconfig | 1 + drivers/gpu/drm/i915/i915_drv.c | 23 +++++++++-------------- drivers/gpu/drm/i915/i915_gem_stolen.c | 19 ++++++++++++++++--- drivers/gpu/drm/i915/intel_display.c | 8 ++++---- drivers/gpu/drm/i915/intel_hdmi.c | 6 +++--- drivers/gpu/drm/i915/intel_panel.c | 4 ++-- drivers/gpu/drm/i915/intel_pm.c | 6 ++++-- drivers/gpu/drm/radeon/atombios_encoders.c | 2 +- drivers/gpu/drm/radeon/cik.c | 5 +++-- drivers/gpu/drm/radeon/evergreen.c | 3 ++- drivers/gpu/drm/radeon/evergreen_smc.h | 2 +- drivers/gpu/drm/radeon/ni.c | 3 ++- drivers/gpu/drm/radeon/r100.c | 2 -- drivers/gpu/drm/radeon/r300.c | 2 -- drivers/gpu/drm/radeon/r420.c | 2 -- drivers/gpu/drm/radeon/r520.c | 2 -- drivers/gpu/drm/radeon/r600.c | 3 ++- drivers/gpu/drm/radeon/radeon_device.c | 5 ++++- drivers/gpu/drm/radeon/radeon_ttm.c | 5 ++++- drivers/gpu/drm/radeon/rs400.c | 2 -- drivers/gpu/drm/radeon/rs600.c | 2 -- drivers/gpu/drm/radeon/rs690.c | 2 -- drivers/gpu/drm/radeon/rv515.c | 2 -- drivers/gpu/drm/radeon/rv770.c | 3 ++- drivers/gpu/drm/radeon/si.c | 3 ++- 27 files changed, 70 insertions(+), 65 deletions(-) [View Less]

1 0

← Newer
1
...
84
85
86
87
88
89
90
...
93
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel March 2014