dri-devel September 2014

dri-devel@lists.freedesktop.org

173 participants
1045 discussions

[BISECTED] 3.17-rc1 radeon screen corruption due to "Always flush the HDP cache before submitting a CS to the GPU"
by Mikael Pettersson 14 Sep '14

14 Sep '14

Since 3.17-rc1 my radeon card (RV370 / X1050 card) causes screen corruption after a while in X + firefox. This still occurs with yesterday's HEAD of Linus' repo. 3.16 and ealier kernels are fine. I ran a bisect, which identified: commit 72a9987edcedb89db988079a03c9b9c65b6ec9ac Author: Michel DÃ¤nzer <michel.daenzer(a)amd.com> Date: Thu Jul 31 18:43:49 2014 +0900 drm/radeon: Always flush the HDP cache before submitting a CS to the GPU as the cause of my screen corruption. Reverting this from 3.17-rc2 (which requires manual intervention due to subsequent changes in radeon_ring_commit()) eliminates the screen corruption. User-space is vanilla Fedora 19 / x86_64 with updates. radeon_drv.so says: [ 62.574] (II) LoadModule: "radeon" [ 62.574] (II) Loading /usr/lib64/xorg/modules/drivers/radeon_drv.so [ 62.574] (II) Module radeon: vendor="X.Org Foundation" [ 62.574] compiled for 1.14.0, module version = 7.1.99 [ 62.574] Module class: X.Org Video Driver [ 62.574] ABI class: X.Org Video Driver, version 14.1 ... [ 62.585] (--) RADEON(0): Chipset: "ATI Radeon X550 (RV370) 5B63 (PCIE)" (ChipID = 0x5b63) See also my original report to LKML: <http://marc.info/?l=linux-kernel&m=140829066726743&w=2> /Mikael

2 6

[Bug 34462] New: 180 second hang on boot, DRM doesn't seem to initialize (firmware issue?)
by bugzilla-daemon＠freedesktop.org 14 Sep '14

14 Sep '14

https://bugs.freedesktop.org/show_bug.cgi?id=34462 Summary: 180 second hang on boot, DRM doesn't seem to initialize (firmware issue?) Product: DRI Version: unspecified Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: owen.riddy(a)gmail.com Created an attachment (id=43540) --> (https://bugs.freedesktop.org/attachment.cgi?id=43540) dmesg from Debian Unstable, fails to load I have a Radeon 3450 graphics card and have been using Debian Squeeze (linux 2.6.32). The card was/is very well supported by the radeon graphics driver, and firmware was being properly loaded (Debian splits the firmware into a separate package from the kernel). Whenever I compiled a newer vanilla kernel KMS didn't work (starting with 2.6.33, I believe. It was a while ago) and X wouldn't load. Every so often I tried a different kernel, and the problem remained. On X, the system would completely hang with a blank screen (I couldn't access any virtual terminals). I assumed I'd mis-configured my kernel and gave up. Debian has now upgraded to linux 2.6.37-1 and this image seems to have the same problem. After upgrading, I get a suspicious 180 second pause when the kernel "populates /dev", which I now attribute to a bug. I'm getting an error message about modprobe blocking (in dmesg). I suspect firmware loading problems: Wheezy (fails, 2.6.37): dmesg | grep -C 4 icroc [ 4.325551] [drm] radeon: 256M of VRAM memory ready [ 4.325554] [drm] radeon: 512M of GTT memory ready. [ 4.325619] [drm] radeon: irq initialized. [ 4.325622] [drm] GART: num cpu pages 131072, num gpu pages 131072 [ 4.326544] [drm] Loading RS780 Microcode [ 4.329997] input: HDA ATI SB Headphone as /devices/pci0000:00/0000:00:14.2/sound/card0/input7 [ 4.414321] radeon 0000:01:05.0: WB enabled [ 4.446469] [drm] ring test succeeded in 1 usecs [ 4.446595] [drm] radeon: ib pool ready. Squeeze (works, 2.6.32): dmesg | grep -C 4 icroc [ 4.616162] [drm] radeon: 256M of VRAM memory ready [ 4.616163] [drm] radeon: 512M of GTT memory ready. [ 4.616204] [drm] radeon: irq initialized. [ 4.616206] [drm] GART: num cpu pages 131072, num gpu pages 131072 [ 4.616624] [drm] Loading RS780 Microcode [ 4.616627] platform radeon_cp.0: firmware: requesting radeon/RS780_pfp.bin [ 4.714728] hda_codec: ALC1200: BIOS auto-probing. [ 4.716081] input: HDA Digital PCBeep as /devices/pci0000:00/0000:00:14.2/input/input6 [ 4.809447] platform radeon_cp.0: firmware: requesting radeon/RS780_me.bin -- [ 4.941941] radeon 0000:02:00.0: irq 30 for MSI/MSI-X [ 4.941946] radeon 0000:02:00.0: radeon: using MSI. [ 4.941978] [drm] radeon: irq initialized. [ 4.941980] [drm] GART: num cpu pages 131072, num gpu pages 131072 [ 4.942370] [drm] Loading RV620 Microcode [ 4.942372] platform radeon_cp.0: firmware: requesting radeon/RV620_pfp.bin [ 4.982496] platform radeon_cp.0: firmware: requesting radeon/RV620_me.bin [ 4.988086] platform radeon_cp.0: firmware: requesting radeon/R600_rlc.bin [ 5.025570] [drm] ring test succeeded in 0 usecs To be sure I haven't tainted the configuration, the method to get a test platform was: * Installed the Squeeze release base system * Upgrade to Wheezy, rebooted to test KMS (virtual terminal screen resolution was large, suggesting it worked) * Upgraded to unstable and reboot, at which point I get the 180 second hang and modprobe errors, as well as a rather low resolution VT. lspci and other info can be found on this bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613922 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 8

[Bug 73338] Fan speed in idle at 40% with radeonsi and at 18% with catalyst
by bugzilla-daemon＠freedesktop.org 13 Sep '14

13 Sep '14

https://bugs.freedesktop.org/show_bug.cgi?id=73338 --- Comment #33 from Chernovsky Oleg <adonai(a)xaker.ru> --- (In reply to comment #32) > Hi, Oleg. Do you require dumps for PITCAIRN chips Yes, I need as much dumps as possible. I hope overdrive v6 works for all SI chips, so I've made simple example program for testing >SI asics, it lays here https://github.com/Adonai/radeon-fancontrol. You can check if it works while in X session with fglrx driver. So you should do the following: 1) install fglrx and configure it 2) switch to text console and stop any X being used 3) rmmod fglrx 4) now start mmiotrace (kernel has pretty nice doc here https://www.kernel.org/doc/Documentation/trace/mmiotrace.txt) 5) modprobe fglrx 6) start X && export DISPLAY=:0 7) now begin to collect data from mmiotrace (via cat trace_pipe &), you can put some marks here 8) start above mentioned program. There should be some noize from GPU fan for 6 seconds, it's normal 9) after it exits (in 10 seconds) collect its output and piped mmiotrace logs and post the results here Thanks! -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 73338] Fan speed in idle at 40% with radeonsi and at 18% with catalyst
by bugzilla-daemon＠freedesktop.org 13 Sep '14

13 Sep '14

https://bugs.freedesktop.org/show_bug.cgi?id=73338 --- Comment #32 from Anton L. <antonl1911(a)gmail.com> --- (In reply to comment #31) > A quick update - I was finally able to retrieve all needed data from fglrx > (via some ADL SDK overdrive6 tinkering). It seems there is a lot of work > (e.g. there is a feature for setting series of pairs > temperature<->fanspeed), but at least I figured out the purpose of used > registers and data values (I hope). > > So I'll try to come up with basic functionality and hwmon interface this > week. Hi, Oleg. Do you require dumps for PITCAIRN chips -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 73338] Fan speed in idle at 40% with radeonsi and at 18% with catalyst
by bugzilla-daemon＠freedesktop.org 13 Sep '14

13 Sep '14

https://bugs.freedesktop.org/show_bug.cgi?id=73338 --- Comment #31 from Chernovsky Oleg <adonai(a)xaker.ru> --- A quick update - I was finally able to retrieve all needed data from fglrx (via some ADL SDK overdrive6 tinkering). It seems there is a lot of work (e.g. there is a feature for setting series of pairs temperature<->fanspeed), but at least I figured out the purpose of used registers and data values (I hope). So I'll try to come up with basic functionality and hwmon interface this week. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 74428] hyperz causes gpu hang in Counter-strike: Source
by bugzilla-daemon＠freedesktop.org 13 Sep '14

13 Sep '14

https://bugs.freedesktop.org/show_bug.cgi?id=74428 --- Comment #6 from Corey Richardson <corey(a)octayn.net> --- I can't reproduce this on git-f976b4c. -- You are receiving this mail because: You are the assignee for the bug.

1 0

3.7+ kernels and Radeon HD 4250 backlight
by Sergey Korshunoff 13 Sep '14

13 Sep '14

Hi! There is a notebook eMashines e442 142G25Mikk Model PEW86 with a video card Radeon HD 4250. Since a kernel 3.7.10 (tested until 3.16.1) it have a problem: screen is a white (not black) when PC is idle. A changes causing problem is: --- linux-3.6.11/drivers/gpu/drm/radeon/radeon_encoders.c 2012-10-01 03:47:46.000000000 +0400 +++ linux-3.7.10/dribers/gpu/drm/radeon/radeon_encoders.c 2012-12-11 07:30:57.000000000 +0400 @@ -153,6 +161,7 @@ void radeon_link_encoder_connector(struct drm_device *dev) { + struct radeon_device *rdev = dev->dev_private; struct drm_connector *connector; struct radeon_connector *radeon_connector; struct drm_encoder *encoder; @@ -163,8 +172,16 @@ radeon_connector = to_radeon_connector(connector); list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) { radeon_encoder = to_radeon_encoder(encoder); - if (radeon_encoder->devices & radeon_connector->devices) + if (radeon_encoder->devices & radeon_connector->devices) { drm_mode_connector_attach_encoder(connector, encoder); + if (radeon_encoder->devices & (ATOM_DEVICE_LCD_SUPPORT)) { + if (rdev->is_atom_bios) + radeon_atom_backlight_init(radeon_encoder, connector); + else + radeon_legacy_backlight_init(radeon_encoder, connector); + rdev->mode_info.bl_encoder = radeon_encoder; + } + } } } } bios is atom. But radeon_atom_backlight_init() do something wrong (I think). Thanks for any suggestions.

1 2

[PULL] topic/core-stuff
by Daniel Vetter 12 Sep '14

12 Sep '14

Hi Dave, Usual pile of random drm patches all over. One i915 one in here for the hdmi doubleclock stuff since I've put both of Clint's patches into this branch. Rebased just now only to check what you've merged already, otherwise this has been hanging out in -nightly for quite a while. Cheers, Daniel The following changes since commit edbaae5a5cab89de0e64b8c03ebd9a8d5d266550: Merge tag 'topic/vblank-rework-2014-09-12' of git://anongit.freedesktop.org/drm-intel into drm-next (2014-09-12 19:04:53 +1000) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/topic/core-stuff-2014-09-12 for you to fetch changes up to 3bd33023f122c16ecbf8a2a74903df52dbce5690: drm: Drop modeset locking from crtc init function (2014-09-12 17:09:24 +0200) ---------------------------------------------------------------- Chris Wilson (1): drm: Include task->name and master status in debugfs clients info Clint Taylor (2): drm/edid: Reduce horizontal timings for pixel replicated modes drm/i915/hdmi: Enable pipe pixel replication for SD interlaced modes Daniel Vetter (1): drm: Drop modeset locking from crtc init function David Herrmann (1): drm: fix division-by-zero on dumb_create() Julia Lawall (1): drm: use c99 initializers in structures Laurent Pinchart (1): drm/gem: Fix kerneldoc typo Randy Dunlap (1): drm: fix drm_modeset_lock.h kernel-doc notation Rob Clark (1): ww-mutex: clarify help text for DEBUG_WW_MUTEX_SLOWPATH drivers/gpu/drm/drm_crtc.c | 9 +-- drivers/gpu/drm/drm_edid.c | 117 +++++++++++++++++++------------------- drivers/gpu/drm/drm_gem.c | 2 +- drivers/gpu/drm/drm_info.c | 27 +++++++-- drivers/gpu/drm/i915/intel_hdmi.c | 15 ++++- drivers/gpu/drm/sti/sti_vtac.c | 12 +++- include/drm/drm_modeset_lock.h | 4 +- lib/Kconfig.debug | 4 ++ 8 files changed, 113 insertions(+), 77 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch

2 1

[PATCH] drm: Assert correct locking for drm_send_vblank_event
by Daniel Vetter 12 Sep '14

12 Sep '14

The comment says that the caller must hold the dev->event_lock spinlock, so let's enforce this. A quick audit over all driver shows that except for the one place in i915 which motivated this all callers fullfill this requirement already. Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: dri-devel(a)lists.freedesktop.org Signed-off-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> --- drivers/gpu/drm/drm_irq.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c index 80ff94ada75e..bf248eb9ffb2 100644 --- a/drivers/gpu/drm/drm_irq.c +++ b/drivers/gpu/drm/drm_irq.c @@ -907,6 +907,9 @@ void drm_send_vblank_event(struct drm_device *dev, int crtc, { struct timeval now; unsigned int seq; + + assert_spin_locked(&dev->event_lock); + if (crtc >= 0) { seq = drm_vblank_count_and_time(dev, crtc, &now); } else { -- 1.9.3

4 6

[RFC v2] device coredump: add new device coredump class
by Johannes Berg 12 Sep '14

12 Sep '14

From: Johannes Berg <johannes.berg(a)intel.com> Many devices run firmware and/or complex hardware, and most of that can have bugs. When it misbehaves, however, it is often much harder to debug than software running on the host. Introduce a "device coredump" mechanism to allow dumping internal device/firmware state through a generalized mechanism. As devices are different and information needed can vary accordingly, this doesn't prescribe a file format - it just provides mechanism to get data to be able to capture it in a generalized way (e.g. in distributions.) Note that generalized capturing of such data may result in privacy issues, so users generally need to be involved. In order to allow certain users/system integrators/... to disable the feature at all, introduce a Kconfig option to override the drivers that would like to have the feature. For now, this provides two ways of dumping data: 1) with a vmalloc'ed area, that is then given to the subsystem and freed after retrieval or timeout 2) with a generalized reader/free function method We could/should add more options, e.g. a list of pages, since the vmalloc area is very limited on some architectures. Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> --- MAINTAINERS | 7 ++ drivers/base/Kconfig | 21 ++++ drivers/base/Makefile | 1 + drivers/base/devcoredump.c | 256 ++++++++++++++++++++++++++++++++++++++++++++ include/linux/devcoredump.h | 35 ++++++ 5 files changed, 320 insertions(+) create mode 100644 drivers/base/devcoredump.c create mode 100644 include/linux/devcoredump.h diff --git a/MAINTAINERS b/MAINTAINERS index 2f85f55c8fb8..8e31d053fb14 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2847,6 +2847,13 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git S: Maintained F: drivers/usb/dwc3/ +DEVICE COREDUMP (DEV_COREDUMP) +M: Johannes Berg <johannes(a)sipsolutions.net> +L: linux-kernel(a)vger.kernel.org +S: Maintained +F: drivers/base/devcoredump.c +F: include/linux/devcoredump.h + DEVICE FREQUENCY (DEVFREQ) M: MyungJoo Ham <myungjoo.ham(a)samsung.com> M: Kyungmin Park <kyungmin.park(a)samsung.com> diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig index 4e7f0ff83ae7..134f763d90fd 100644 --- a/drivers/base/Kconfig +++ b/drivers/base/Kconfig @@ -165,6 +165,27 @@ config FW_LOADER_USER_HELPER_FALLBACK If you are unsure about this, say N here. +config WANT_DEV_COREDUMP + bool + help + Drivers should "select" this option if they desire to use the + device coredump mechanism. + +config DISABLE_DEV_COREDUMP + bool "Disable device coredump" if EXPERT + help + Disable the device coredump mechanism despite drivers wanting to + use it; this allows for more sensitive systems or systems that + don't want to ever access the information to not have the code, + nor keep any data. + + If unsure, say N. + +config DEV_COREDUMP + bool + default y if WANT_DEV_COREDUMP + depends on !DISABLE_DEV_COREDUMP + config DEBUG_DRIVER bool "Driver Core verbose debug messages" depends on DEBUG_KERNEL diff --git a/drivers/base/Makefile b/drivers/base/Makefile index 4aab26ec0292..6922cd6850a2 100644 --- a/drivers/base/Makefile +++ b/drivers/base/Makefile @@ -21,6 +21,7 @@ obj-$(CONFIG_SYS_HYPERVISOR) += hypervisor.o obj-$(CONFIG_REGMAP) += regmap/ obj-$(CONFIG_SOC_BUS) += soc.o obj-$(CONFIG_PINCTRL) += pinctrl.o +obj-$(CONFIG_DEV_COREDUMP) += devcoredump.o ccflags-$(CONFIG_DEBUG_DRIVER) := -DDEBUG diff --git a/drivers/base/devcoredump.c b/drivers/base/devcoredump.c new file mode 100644 index 000000000000..d6ecf13a5903 --- /dev/null +++ b/drivers/base/devcoredump.c @@ -0,0 +1,256 @@ +/* + * This file is provided under the GPLv2 license. + * + * GPL LICENSE SUMMARY + * + * Copyright(c) 2014 Intel Mobile Communications GmbH + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of version 2 of the GNU General Public License as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * The full GNU General Public License is included in this distribution + * in the file called COPYING. + * + * Contact Information: + * Intel Linux Wireless <ilw(a)linux.intel.com> + * Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497 + */ +#include <linux/module.h> +#include <linux/device.h> +#include <linux/devcoredump.h> +#include <linux/list.h> +#include <linux/slab.h> +#include <linux/fs.h> +#include <linux/workqueue.h> + +MODULE_AUTHOR("Johannes Berg <johannes(a)sipsolutions.net>"); +MODULE_DESCRIPTION("Device Coredump support"); +MODULE_LICENSE("GPL"); + +/* if data isn't read by userspace after 5 minutes then delete it */ +#define DEVCD_TIMEOUT (HZ * 60 * 5) + +struct devcd_entry { + struct device devcd_dev; + const void *data; + size_t datalen; + struct module *owner; + ssize_t (*read)(char *buffer, loff_t offset, size_t count, + const void *data, size_t datalen); + void (*free)(const void *data); + struct delayed_work del_wk; + struct device *failing_dev; +}; + +static struct devcd_entry *dev_to_devcd(struct device *dev) +{ + return container_of(dev, struct devcd_entry, devcd_dev); +} + +static void devcd_dev_release(struct device *dev) +{ + struct devcd_entry *devcd = dev_to_devcd(dev); + + devcd->free(devcd->data); + module_put(devcd->owner); + + /* + * this seems racy, but I don't see a notifier or such on + * a struct device to know when it goes away? + */ + if (devcd->failing_dev->kobj.sd) + sysfs_delete_link(&devcd->failing_dev->kobj, &dev->kobj, + "dev_coredump"); + + put_device(devcd->failing_dev); + kfree(devcd); +} + +static void devcd_del(struct work_struct *wk) +{ + struct devcd_entry *devcd; + + devcd = container_of(wk, struct devcd_entry, del_wk.work); + + device_del(&devcd->devcd_dev); + put_device(&devcd->devcd_dev); +} + +static ssize_t devcd_data_read(struct file *filp, struct kobject *kobj, + struct bin_attribute *bin_attr, + char *buffer, loff_t offset, size_t count) +{ + struct device *dev = kobj_to_dev(kobj); + struct devcd_entry *devcd = dev_to_devcd(dev); + + return devcd->read(buffer, offset, count, devcd->data, devcd->datalen); +} + +static ssize_t devcd_data_write(struct file *filp, struct kobject *kobj, + struct bin_attribute *bin_attr, + char *buffer, loff_t offset, size_t count) +{ + struct device *dev = kobj_to_dev(kobj); + struct devcd_entry *devcd = dev_to_devcd(dev); + + mod_delayed_work(system_wq, &devcd->del_wk, 0); + + return count; +} + +static struct bin_attribute devcd_attr_data = { + .attr = { .name = "data", .mode = S_IRUSR | S_IWUSR, }, + .size = 0, + .read = devcd_data_read, + .write = devcd_data_write, +}; + +static struct bin_attribute *devcd_dev_bin_attrs[] = { + &devcd_attr_data, NULL, +}; + +static const struct attribute_group devcd_dev_group = { + .bin_attrs = devcd_dev_bin_attrs, +}; + +static const struct attribute_group *devcd_dev_groups[] = { + &devcd_dev_group, NULL, +}; + +static struct class devcd_class = { + .name = "devcoredump", + .owner = THIS_MODULE, + .dev_release = devcd_dev_release, + .dev_groups = devcd_dev_groups, +}; + +static ssize_t devcd_readv(char *buffer, loff_t offset, size_t count, + const void *data, size_t datalen) +{ + if (offset > datalen) + return -EINVAL; + + if (offset + count > datalen) + count = datalen - offset; + + if (count) + memcpy(buffer, ((u8 *)data) + offset, count); + + return count; +} + +/** + * dev_coredumpv - create firmware coredump with vmalloc data + * @dev: the struct device for the crashed device + * @data: vmalloc data containing the firmware coredump + * @datalen: length of the data + * @gfp: allocation flags + */ +void dev_coredumpv(struct device *dev, const void *data, size_t datalen, + gfp_t gfp) +{ + dev_coredumpm(dev, NULL, data, datalen, gfp, devcd_readv, vfree); +} +EXPORT_SYMBOL(dev_coredumpv); + +static int devcd_match_failing(struct device *dev, const void *failing) +{ + struct devcd_entry *devcd = dev_to_devcd(dev); + + return devcd->failing_dev == failing; +} + +/** + * dev_coredumpm - create firmware coredump with read/free methods + * @dev: the struct device for the crashed device + * @data: data cookie for the @read/@free functions + * @datalen: length of the data + * @gfp: allocation flags + * @read: function to read from the given buffer + * @free: function to free the given buffer + */ +void dev_coredumpm(struct device *dev, struct module *owner, + const void *data, size_t datalen, gfp_t gfp, + ssize_t (*read)(char *buffer, loff_t offset, size_t count, + const void *data, size_t datalen), + void (*free)(const void *data)) +{ + static atomic_t devcd_count = ATOMIC_INIT(0); + struct devcd_entry *devcd; + struct device *existing; + + existing = class_find_device(&devcd_class, NULL, dev, + devcd_match_failing); + if (existing) { + put_device(existing); + return; + } + + if (!try_module_get(owner)) + return; + + devcd = kzalloc(sizeof(*devcd), gfp); + if (!devcd) + goto put_module; + + devcd->owner = owner; + devcd->data = data; + devcd->datalen = datalen; + devcd->read = read; + devcd->free = free; + devcd->failing_dev = get_device(dev); + + device_initialize(&devcd->devcd_dev); + + dev_set_name(&devcd->devcd_dev, "devcd%d", + atomic_inc_return(&devcd_count)); + devcd->devcd_dev.class = &devcd_class; + + if (device_add(&devcd->devcd_dev)) + goto put_device; + + if (sysfs_create_link(&devcd->devcd_dev.kobj, &dev->kobj, + "failing_device")) + /* nothing - symlink will be missing */; + + if (sysfs_create_link(&dev->kobj, &devcd->devcd_dev.kobj, + "dev_coredump")) + /* nothing - symlink will be missing */; + + INIT_DELAYED_WORK(&devcd->del_wk, devcd_del); + schedule_delayed_work(&devcd->del_wk, DEVCD_TIMEOUT); + + return; + put_device: + put_device(&devcd->devcd_dev); + put_module: + module_put(owner); +} +EXPORT_SYMBOL(dev_coredumpm); + +static int __init devcoredump_init(void) +{ + return class_register(&devcd_class); +} +module_init(devcoredump_init); + +static int devcd_free(struct device *dev, void *data) +{ + struct devcd_entry *devcd = dev_to_devcd(dev); + + flush_delayed_work(&devcd->del_wk); + return 0; +} + +static void __exit devcoredump_exit(void) +{ + class_for_each_device(&devcd_class, NULL, NULL, devcd_free); + class_unregister(&devcd_class); +} +module_exit(devcoredump_exit); diff --git a/include/linux/devcoredump.h b/include/linux/devcoredump.h new file mode 100644 index 000000000000..c0a360e99f64 --- /dev/null +++ b/include/linux/devcoredump.h @@ -0,0 +1,35 @@ +#ifndef __DEVCOREDUMP_H +#define __DEVCOREDUMP_H + +#include <linux/device.h> +#include <linux/module.h> +#include <linux/vmalloc.h> + +#ifdef CONFIG_DEV_COREDUMP +void dev_coredumpv(struct device *dev, const void *data, size_t datalen, + gfp_t gfp); + +void dev_coredumpm(struct device *dev, struct module *owner, + const void *data, size_t datalen, gfp_t gfp, + ssize_t (*read)(char *buffer, loff_t offset, size_t count, + const void *data, size_t datalen), + void (*free)(const void *data)); +#else +static inline void dev_coredumpv(struct device *dev, const void *data, + size_t datalen, gfp_t gfp) +{ + vfree(data); +} + +static inline void +dev_coredumpm(struct device *dev, struct module *owner, + const void *data, size_t datalen, gfp_t gfp, + ssize_t (*read)(char *buffer, loff_t offset, size_t count, + const void *data, size_t datalen), + void (*free)(const void *data)) +{ + free(data); +} +#endif /* CONFIG_DEV_COREDUMP */ + +#endif /* __DEVCOREDUMP_H */ -- 2.1.0

5 8

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel September 2014