[PATCH] Fix annoyingly awkward typo in drm_edid_load.c
Fix egregious typo in comment. Signed-off-by: Valdis Kletnieks --- a/drivers/gpu/drm/drm_edid_load.c 2016-04-20 17:54:27.208059935 -0400 +++ b/drivers/gpu/drm/drm_edid_load.c 2016-05-30 02:15:43.747105384 -0400 @@ -271,7 +271,7 @@ * by commas, search through the list looking for one that * matches the connector. * -* If there's one or more that don't't specify a connector, keep +* If there's one or more that doesn't specify a connector, keep * the last one found one as a fallback. */ fwstr = kstrdup(edid_firmware, GFP_KERNEL);
Re: 3.5-rc5: radeon acceleration regression on Transmeta system
On Mon, 09 Jul 2012 14:30:40 +0300, Meelis Roos said: It's actually more complicated than that. Old kernel images started misbehaving from around 2.6.35-rc5 and any kernel older than that was OK. When I recompiled the older kernels with squeeze gcc (migh have been lenny gcc before, or different answers to make oldconfig), anything from current git down to 2.6.33 is broken with radeon.modeset=1 and works (I What releases of GCC were those? I'm chasing an issue where compiling with 4.7.[01] breaks but 4.6.2 is OK, wondering if we're chasing the same thing. pgpky9saflsmH.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [V5 PATCH 1/4] drivers-gpu-drm-allow-to-load-edid-firmware.patch
On Thu, 15 Mar 2012 15:56:24 BST, Carsten Emde said: Broken monitors and/or broken graphic boards may send erroneous or no EDID data. This also applies to broken KVM devices that are unable to correctly forward the EDID data of the connected monitor but invent their own fantasy data. Documentation/EDID/HOWTO.txt| 39 + Documentation/EDID/Makefile | 26 +++ Documented *and* a Makefile to automate it. Nice. :) That addresses my comments.. Acked-by: Valdis Kletnieks valdis.kletni...@vt.edu pgpsTPtB0bBud.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drivers-gpu-drm-allow-to-load-edid-firmware.patch
On Sat, 10 Mar 2012 21:20:15 +0100, Carsten Emde said: EDID data source files are provided for documentation purpose and as a template to create EDID data sets for other screen resolutions. Note that source compilation is not part of the build process, but needs to be done manually, e.g. #!/bin/bash cd firmware/edid for i in [1-9]*.S do Would it be possible to include a version of this patch's Changelog as a file under Documentation/fixing-broken-edid.txt or something, so people don't have to go and find the git commit log to know things like you need to run dos2unix? Be a shame to have a changelog that does such a good job of documenting what you need to do, and have it lost in git... pgp5kgga7tOZm.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On Tue, 24 May 2011 14:30:59 +0200, Jacek Luczak said:
2011/5/24 Jan Engelhardt jeng...@medozas.de:
On Tuesday 2011-05-24 01:33, Linus Torvalds wrote:
Another advantage of switching numbering models (ie 3.0 instead of
2.8.x) would be that it would also make the odd numbers are also
numbers transition much more natural.
Because of our historical even/odd model, I wouldn't do a 2.7.x -
there's just too much history of 2.1, 2.3, 2.5 being development
trees.
.oO(Though once 2.{7 or more, odd} trickle into the distros, it would
become pretty much apparent that they are not devel.)
And then in another few years (probably before getting close to 3.40,
so I'm not going to make a big deal of 3 = third decade), I'd just
do 4.0 etc.
While 2.6 has certainly worn out, already thinking of a 4.0 is highly
reminiscient of the version number arms race Firefox and ChromeBrowser
are doing currently.
Because all our releases are supposed to be stable releases these
days, and if we get rid of one level of numbering, I feel perfectly
fine with getting rid of the even/odd history too.
If I remember past-time discussions right, ELF was the contributing
factor to bump the major number to 2.0 back then; ever since 2.0, no
similarly breakthrough-ing event has occurred.
What then about BKL removal? Nice place to celebrate with version jump
and heaving some beers.
Well, if we're looking at ELF-sized ABI changes, how about 3.0 be the
release where we re-sync the syscall numbers on all the archs? ;)
pgp21lBpIoZeR.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
On Mon, 18 Oct 2010 17:40:04 PDT, Greg KH said: I do have access to this hardware, but its on an old single processor laptop, so any work that it would take to help do this development, really wouldn't be able to be tested to be valid at all. The i810 is a graphics chipset embedded on the memory controller, which was designed for the Intel Pentium II, Pentium III, and Celeron CPUs. Page 8 of the datasheet specifically says: Processor/Host Bus Support - Optimized for the Intel Pentium II processor, Intel Pentium III processor, and Intel CeleronTM processor - Supports processor 370-Pin Socket and SC242 connectors - Supports 32-Bit System Bus Addressing - 4 deep in-order queue; 4 or 1 deep request queue - Supports Uni-processor systems only So no need to clean it up for multiprocessor support. http://download.intel.com/design/chipsets/datashts/29067602.pdf http://www.intel.com/design/chipsets/specupdt/29069403.pdf pgpwXvtEAuS8q.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/15] change default_llseek action
On Tue, 14 Sep 2010 22:22:28 +0200, Arnd Bergmann said: This changes *all* instances of struct file_operations in the kernel to have a .llseek operation and then changes the default to no_llseek, which returns -ESPIPE, which is what we had decided some time ago in a discussion with Christoph Hellwig. I don't suppose there's any clean way to throw a build error or a printk_on_once() or something if we encounter an unconverted 'struct file_operations', is there? I have this creeping fear that this patch will go upstream during the merge window - as will 12 new staging/ drivers from authors who didn't get the memo yet. Other than the missed converting a new usage issue, it looks OK to me. pgpS2XWkq1seX.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
mmotm 2010-07-27 - nouveau lockdep issues.
On Tue, 27 Jul 2010 14:56:50 PDT, a...@linux-foundation.org said:
The mm-of-the-moment snapshot 2010-07-27-14-56 has been uploaded to
http://userweb.kernel.org/~akpm/mmotm/
Hit this while the X server was on its way down during a 'shutdown -r now'.
Worked fine
in -rc5-mmotm0719. 'e16' is the Enlightenment window manager, if that matters.
[ 93.181787] [drm:output_poll_execute] *ERROR* delayed enqueue failed 1
[ 99.802836] [drm] nouveau :01:00.0: Allocating FIFO number 4
[ 99.808875] [drm] nouveau :01:00.0: nouveau_channel_alloc: initialised
FIFO 4
[ 103.262226] [drm:output_poll_execute] *ERROR* delayed enqueue failed 1
[ 113.341948] [drm:output_poll_execute] *ERROR* delayed enqueue failed 1
[ 123.421836] [drm:output_poll_execute] *ERROR* delayed enqueue failed 1
[ 123.550520] [drm] nouveau :01:00.0: nouveau_channel_free: freeing fifo 4
[ 123.551253]
[ 123.551253] ==
[ 123.551253] [ INFO: HARDIRQ-safe - HARDIRQ-unsafe lock order detected ]
[ 123.551253] 2.6.35-rc6-mmotm0727 #1
[ 123.551253] --
[ 123.551253] e16/3822 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
[ 123.551253] ((mm-unused_lock)-rlock){+.+...}, at: [812a94bc]
drm_mm_put_block+0x10e/0x142
[ 123.551253]
[ 123.551253] and this task is already holding:
[ 123.551253] ((dev_priv-context_switch_lock)-rlock){-.}, at:
[812bdbab] nouveau_channel_free+0x10f/0x233
[ 123.551253] which would create a new lock dependency:
[ 123.551253] ((dev_priv-context_switch_lock)-rlock){-.} -
((mm-unused_lock)-rlock){+.+...}
[ 123.551253]
[ 123.551253] but this new dependency connects a HARDIRQ-irq-safe lock:
[ 123.551253] ((dev_priv-context_switch_lock)-rlock){-.}
[ 123.551253] ... which became HARDIRQ-irq-safe at:
[ 123.551253] [81065043] __lock_acquire+0x301/0xd6a
[ 123.551253] [81065fca] lock_acquire+0x10a/0x130
[ 123.551253] [81594dda] _raw_spin_lock_irqsave+0x44/0x57
[ 123.551253] [812c264b] nouveau_irq_handler+0x63/0x1920
[ 123.551253] [810817bb] handle_IRQ_event+0xad/0x213
[ 123.551253] [81083bd2] handle_fasteoi_irq+0xd1/0x115
[ 123.551253] [81004b6e] handle_irq+0x122/0x133
[ 123.551253] [8100499f] do_IRQ+0x57/0xaf
[ 123.551253]
[ 123.604031] [drm] nouveau :01:00.0: GPU lockup - switching to software
fbcon
[ 123.604031] [81595cd3] ret_from_intr+0x0/0xf
[ 123.604031] [81000c73] cpu_idle+0x85/0x169
[ 123.604031] [81b62061] start_secondary+0x1b1/0x1b5
[ 123.604031]
[ 123.604031] to a HARDIRQ-irq-unsafe lock:
[ 123.604031] ((mm-unused_lock)-rlock){+.+...}
[ 123.604031] ... which became HARDIRQ-irq-unsafe at:
[ 123.604031] ... [810650c4] __lock_acquire+0x382/0xd6a
[ 123.604031] [81065fca] lock_acquire+0x10a/0x130
[ 123.604031] [81594ce1] _raw_spin_lock+0x36/0x45
[ 123.604031] [812a9669] drm_mm_pre_get+0x24/0xb2
[ 123.604031] [812b748b] ttm_bo_init+0x1fe/0x3c0
[ 123.604031] [812c5dce] nouveau_bo_new+0x3ae/0x423
[ 123.604031] [812bf2c8] nouveau_mem_init+0x293/0x487
[ 123.604031] [812bce55] nouveau_card_init+0xa5e/0xd52
[ 123.604031] [812bd675] nouveau_load+0x519/0x528
[ 123.604031] [812a74af] drm_get_pci_dev+0x174/0x26a
[ 123.604031] [8158a14e] nouveau_pci_probe+0x10/0x12
[ 123.604031] [812228ce] local_pci_probe+0x3f/0x70
[ 123.604031] [81222c4c] pci_device_probe+0x65/0x96
[ 123.604031] [8130a840] driver_probe_device+0xe8/0x182
[ 123.604031] [8130a924] __driver_attach+0x4a/0x6b
[ 123.604031] [81309a2f] bus_for_each_dev+0x57/0x83
[ 123.604031] [8130a505] driver_attach+0x19/0x1b
[ 123.604031] [8130a147] bus_add_driver+0xae/0x205
[ 123.604031] [8130ab80] driver_register+0xb5/0x122
[ 123.604031] [81222e82] __pci_register_driver+0x61/0xcd
[ 123.604031] [812a7839] drm_pci_init+0x31/0x98
[ 123.604031] [812a003f] drm_init+0x5d/0x61
[ 123.604031] [81b4e59a] nouveau_init+0x48/0x4a
[ 123.604031] [810002ff] do_one_initcall+0x7a/0x12f
[ 123.604031] [81b2ccae] kernel_init+0x138/0x1c2
[ 123.604031] [81003554] kernel_thread_helper+0x4/0x10
[ 123.604031]
[ 123.604031] other info that might help us debug this:
[ 123.604031]
[ 123.604031] 1 lock held by e16/3822:
[ 123.604031] #0: ((dev_priv-context_switch_lock)-rlock){-.}, at:
[812bdbab] nouveau_channel_free+0x10f/0x233
[ 123.604031]
[ 123.604031] the dependencies between HARDIRQ-irq-safe lock and the holding
lock:
[ 123.604031] - ((dev_priv-context_switch_lock)-rlock){-.} ops: 15 {
[ 123.604031]IN-HARDIRQ-W at:
[ 123.604031][81065043]
Re: [PATCH 4/8]drivers:tmp.c Fix warning: variable 'rc' set but not used
On Mon, 14 Jun 2010 13:26:44 PDT, Justin P. Mattock said: Im getting this warning when compiling: CC drivers/char/tpm/tpm.o drivers/char/tpm/tpm.c: In function 'tpm_gen_interrupt': drivers/char/tpm/tpm.c:508:10: warning: variable 'rc' set but not used The below patch gets rid of the warning, but I'm not sure if it's the best solution. rc = transmit_cmd(chip, tpm_cmd, TPM_INTERNAL_RESULT_SIZE, attempting to determine the timeouts); + if (!rc) + rc = 0; } Good thing that's a void function. ;) Unless transmit_cmd() is marked 'must_check', maybe losing the 'rc =' would be a better solution? pgpjRfgTzM2eX.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
mmotm 2010-04-28 - nouveau driver issues
On Wed, 28 Apr 2010 16:53:32 PDT, a...@linux-foundation.org said: The mm-of-the-moment snapshot 2010-04-28-16-53 has been uploaded to http://userweb.kernel.org/~akpm/mmotm/ The nouveau driver had issues during boot, caused plymouth to have indigestion and fall back to 24x80 character mode. This happened sometime between -mmotm0422 and -mmotm0428. Looks like something in linux-next, cc'ing anybody who apparently touched nouveau code. Will bisect if nobody has a good idea what happened. The X server was able to init the card and get gdm started just fine. lspci says: 01:00.0 VGA compatible controller: nVidia Corporation G98M [Quadro NVS 160M] (rev a1) [1.038152] [drm] nouveau :01:00.0: Detected 256MiB VRAM [1.194505] [TTM] Zone kernel: Available graphics memory: 2013496 kiB. [1.194508] [ttm] Initializing pool allocator. [1.194896] [ cut here ] [1.194903] WARNING: at arch/x86/mm/ioremap.c:111 __ioremap_caller+0x238/0x3f4() [1.194906] Hardware name: Latitude E6500 [1.194908] Modules linked in: [1.194912] Pid: 1, comm: swapper Not tainted 2.6.34-rc5-mmotm0428 #1 [1.194915] Call Trace: [1.194921] [81038936] warn_slowpath_common+0x80/0x98 [1.194925] [81038963] warn_slowpath_null+0x15/0x17 [1.194929] [8102064a] __ioremap_caller+0x238/0x3f4 [1.194934] [812b27ba] ? ttm_mem_reg_ioremap+0x54/0x7b [1.194939] [810d6aff] ? kmem_cache_alloc_notrace+0x68/0xc0 [1.194942] [8102088f] ioremap_nocache+0x12/0x14 [1.194946] [812b27ba] ttm_mem_reg_ioremap+0x54/0x7b [1.194950] [812b2b5c] ttm_bo_move_memcpy+0x5e/0x3e0 [1.194954] [812a4d7d] ? drm_mm_split_at_start+0x79/0x95 [1.194959] [8120ec2d] ? do_raw_spin_unlock+0xd0/0xfa [1.194964] [812c21cf] nouveau_bo_move+0x19e/0x222 [1.194968] [812afe79] ttm_bo_handle_move_mem+0x1b4/0x2c0 [1.194972] [812b1d9e] ttm_bo_move_buffer+0xf4/0x14d [1.194976] [81210b2d] ? __list_add+0xb7/0xd2 [1.194980] [812b1ee3] ttm_bo_validate+0xec/0x13e [1.194983] [8120e900] ? do_raw_write_unlock+0x7e/0xc8 [1.194987] [812b2315] ttm_bo_init+0x3e0/0x419 [1.194990] [812c2957] nouveau_bo_new+0x394/0x405 [1.194994] [812c2510] ? nouveau_bo_del_ttm+0x0/0xb3 [1.194997] [812a4cca] ? drm_mm_init+0x63/0x6b [1.195015] [812ba319] nouveau_mem_init+0x262/0x42f [1.195019] [812b7e02] nouveau_card_init+0xb09/0xe35 [1.195023] [812b86de] nouveau_load+0x4e6/0x50c [1.195028] [812a0fee] drm_get_dev+0x3bf/0x4cc [1.195034] [8158c3be] nouveau_pci_probe+0x10/0x12 [1.195039] [8121d71b] local_pci_probe+0x12/0x16 [1.195043] [8121db88] pci_device_probe+0x60/0x8f [1.195048] [813082e3] ? driver_sysfs_add+0x47/0x6c [1.195052] [81308462] driver_probe_device+0xde/0x178 [1.195056] [81308558] __driver_attach+0x5c/0x80 [1.195060] [813084fc] ? __driver_attach+0x0/0x80 [1.195063] [813084fc] ? __driver_attach+0x0/0x80 [1.195067] [81307a47] bus_for_each_dev+0x54/0x89 [1.195071] [8130829a] driver_attach+0x19/0x1b [1.195075] [81307ee2] bus_add_driver+0xb4/0x206 [1.195079] [81308857] driver_register+0xb8/0x129 [1.195083] [8121ddbe] __pci_register_driver+0x63/0xd3 [1.195088] [81b4f4c4] ? nouveau_init+0x0/0x52 [1.195092] [8129ba89] drm_init+0x6b/0xd1 [1.195096] [81b4f4c4] ? nouveau_init+0x0/0x52 [1.195100] [81b4f514] nouveau_init+0x50/0x52 [1.195104] [810001ef] do_one_initcall+0x59/0x14e [1.195109] [81b2e68a] kernel_init+0x144/0x1ce [1.195113] [81003414] kernel_thread_helper+0x4/0x10 [1.195117] [81598a40] ? restore_args+0x0/0x30 [1.195121] [81b2e546] ? kernel_init+0x0/0x1ce [1.195125] [81003410] ? kernel_thread_helper+0x0/0x10 [1.195192] ---[ end trace f31dec58d66d24a5 ]--- [1.195323] [drm] nouveau :01:00.0: failed to reserve VGA memory [1.195360] resource map sanity check conflict: 0x0 0xf 0xa 0xb PCI Bus :00 [1.195363] [ cut here ] [1.195366] WARNING: at arch/x86/mm/ioremap.c:98 __ioremap_caller+0x13b/0x3f4() [1.195369] Hardware name: Latitude E6500 [1.195371] Info: mapping multiple BARs. Your kernel is fine. [1.195373] Modules linked in: [1.195376] Pid: 1, comm: swapper Tainted: GW 2.6.34-rc5-mmotm0428 #1 [1.195378] Call Trace: [1.195382] [81038936] warn_slowpath_common+0x80/0x98 [1.195386] [810389e2] warn_slowpath_fmt+0x41/0x43 [1.195390] [8102054d] __ioremap_caller+0x13b/0x3f4 [1.195394]
