<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers/gpu, branch v3.18</title>
<subtitle>Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
</subtitle>
<id>https://git.shady.money/linux/atom?h=v3.18</id>
<link rel='self' href='https://git.shady.money/linux/atom?h=v3.18'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/'/>
<updated>2014-12-05T01:12:29Z</updated>
<entry>
<title>Merge tag 'drm-intel-fixes-2014-12-04' of git://anongit.freedesktop.org/drm-intel into drm-fixes</title>
<updated>2014-12-05T01:12:29Z</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@redhat.com</email>
</author>
<published>2014-12-05T01:12:29Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=3e3282c0a23d8eb9438dcf4ac908a5eb48c7038b'/>
<id>urn:sha1:3e3282c0a23d8eb9438dcf4ac908a5eb48c7038b</id>
<content type='text'>
Silence some pch fifo underrun reports and panel locking backtraces,
both cc: stable.

* tag 'drm-intel-fixes-2014-12-04' of git://anongit.freedesktop.org/drm-intel:
  drm/i915: Unlock panel even when LVDS is disabled
  drm/i915: More cautious with pch fifo underruns
</content>
</entry>
<entry>
<title>drm/radeon: kernel panic in drm_calc_vbltimestamp_from_scanoutpos with 3.18.0-rc6</title>
<updated>2014-12-02T20:45:33Z</updated>
<author>
<name>Petr Mladek</name>
<email>pmladek@suse.cz</email>
</author>
<published>2014-11-27T15:57:21Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=f5475cc43c899e33098d4db44b7c5e710f16589d'/>
<id>urn:sha1:f5475cc43c899e33098d4db44b7c5e710f16589d</id>
<content type='text'>
I was unable too boot 3.18.0-rc6 because of the following kernel
panic in drm_calc_vbltimestamp_from_scanoutpos():

    [drm] Initialized drm 1.1.0 20060810
    [drm] radeon kernel modesetting enabled.
    [drm] initializing kernel modesetting (RV100 0x1002:0x515E 0x15D9:0x8080).
    [drm] register mmio base: 0xC8400000
    [drm] register mmio size: 65536
    radeon 0000:0b:01.0: VRAM: 128M 0x00000000D0000000 - 0x00000000D7FFFFFF (16M used)
    radeon 0000:0b:01.0: GTT: 512M 0x00000000B0000000 - 0x00000000CFFFFFFF
    [drm] Detected VRAM RAM=128M, BAR=128M
    [drm] RAM width 16bits DDR
    [TTM] Zone  kernel: Available graphics memory: 3829346 kiB
    [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
    [TTM] Initializing pool allocator
    [TTM] Initializing DMA pool allocator
    [drm] radeon: 16M of VRAM memory ready
    [drm] radeon: 512M of GTT memory ready.
    [drm] GART: num cpu pages 131072, num gpu pages 131072
    [drm] PCI GART of 512M enabled (table at 0x0000000037880000).
    radeon 0000:0b:01.0: WB disabled
    radeon 0000:0b:01.0: fence driver on ring 0 use gpu addr 0x00000000b0000000 and cpu addr 0xffff8800bbbfa000
    [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
    [drm] Driver supports precise vblank timestamp query.
    [drm] radeon: irq initialized.
    [drm] Loading R100 Microcode
    radeon 0000:0b:01.0: Direct firmware load for radeon/R100_cp.bin failed with error -2
    radeon_cp: Failed to load firmware "radeon/R100_cp.bin"
    [drm:r100_cp_init] *ERROR* Failed to load firmware!
    radeon 0000:0b:01.0: failed initializing CP (-2).
    radeon 0000:0b:01.0: Disabling GPU acceleration
    [drm] radeon: cp finalized
    BUG: unable to handle kernel NULL pointer dereference at 000000000000025c
    IP: [&lt;ffffffff8150423b&gt;] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320
    PGD 0
    Oops: 0000 [#1] SMP
    Modules linked in:
    CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.18.0-rc6-4-default #2649
    Hardware name: Supermicro X7DB8/X7DB8, BIOS 6.00 07/26/2006
    task: ffff880234da2010 ti: ffff880234da4000 task.ti: ffff880234da4000
    RIP: 0010:[&lt;ffffffff8150423b&gt;]  [&lt;ffffffff8150423b&gt;] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320
    RSP: 0000:ffff880234da7918  EFLAGS: 00010086
    RAX: ffffffff81557890 RBX: 0000000000000000 RCX: ffff880234da7a48
    RDX: ffff880234da79f4 RSI: 0000000000000000 RDI: ffff880232e15000
    RBP: ffff880234da79b8 R08: 0000000000000000 R09: 0000000000000000
    R10: 000000000000000a R11: 0000000000000001 R12: ffff880232dda1c0
    R13: ffff880232e1518c R14: 0000000000000292 R15: ffff880232e15000
    FS:  0000000000000000(0000) GS:ffff88023fc40000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    CR2: 000000000000025c CR3: 0000000002014000 CR4: 00000000000007e0
    Stack:
     ffff880234da79d8 0000000000000286 ffff880232dcbc00 0000000000002480
     ffff880234da7958 0000000000000296 ffff880234da7998 ffffffff8151b51d
     ffff880234da7a48 0000000032dcbeb0 ffff880232dcbc00 ffff880232dcbc58
    Call Trace:
     [&lt;ffffffff8151b51d&gt;] ? drm_vma_offset_remove+0x1d/0x110
     [&lt;ffffffff8152dc98&gt;] radeon_get_vblank_timestamp_kms+0x38/0x60
     [&lt;ffffffff8152076a&gt;] ? ttm_bo_release_list+0xba/0x180
     [&lt;ffffffff81503751&gt;] drm_get_last_vbltimestamp+0x41/0x70
     [&lt;ffffffff81503933&gt;] vblank_disable_and_save+0x73/0x1d0
     [&lt;ffffffff81106b2f&gt;] ? try_to_del_timer_sync+0x4f/0x70
     [&lt;ffffffff81505245&gt;] drm_vblank_cleanup+0x65/0xa0
     [&lt;ffffffff815604fa&gt;] radeon_irq_kms_fini+0x1a/0x70
     [&lt;ffffffff8156c07e&gt;] r100_init+0x26e/0x410
     [&lt;ffffffff8152ae3e&gt;] radeon_device_init+0x7ae/0xb50
     [&lt;ffffffff8152d57f&gt;] radeon_driver_load_kms+0x8f/0x210
     [&lt;ffffffff81506965&gt;] drm_dev_register+0xb5/0x110
     [&lt;ffffffff8150998f&gt;] drm_get_pci_dev+0x8f/0x200
     [&lt;ffffffff815291cd&gt;] radeon_pci_probe+0xad/0xe0
     [&lt;ffffffff8141a365&gt;] local_pci_probe+0x45/0xa0
     [&lt;ffffffff8141b741&gt;] pci_device_probe+0xd1/0x130
     [&lt;ffffffff81633dad&gt;] driver_probe_device+0x12d/0x3e0
     [&lt;ffffffff8163413b&gt;] __driver_attach+0x9b/0xa0
     [&lt;ffffffff816340a0&gt;] ? __device_attach+0x40/0x40
     [&lt;ffffffff81631cd3&gt;] bus_for_each_dev+0x63/0xa0
     [&lt;ffffffff8163378e&gt;] driver_attach+0x1e/0x20
     [&lt;ffffffff81633390&gt;] bus_add_driver+0x180/0x240
     [&lt;ffffffff81634914&gt;] driver_register+0x64/0xf0
     [&lt;ffffffff81419cac&gt;] __pci_register_driver+0x4c/0x50
     [&lt;ffffffff81509bf5&gt;] drm_pci_init+0xf5/0x120
     [&lt;ffffffff821dc871&gt;] ? ttm_init+0x6a/0x6a
     [&lt;ffffffff821dc908&gt;] radeon_init+0x97/0xb5
     [&lt;ffffffff810002fc&gt;] do_one_initcall+0xbc/0x1f0
     [&lt;ffffffff810e3278&gt;] ? __wake_up+0x48/0x60
     [&lt;ffffffff8218e256&gt;] kernel_init_freeable+0x18a/0x215
     [&lt;ffffffff8218d983&gt;] ? initcall_blacklist+0xc0/0xc0
     [&lt;ffffffff818a78f0&gt;] ? rest_init+0x80/0x80
     [&lt;ffffffff818a78fe&gt;] kernel_init+0xe/0xf0
     [&lt;ffffffff818c0c3c&gt;] ret_from_fork+0x7c/0xb0
     [&lt;ffffffff818a78f0&gt;] ? rest_init+0x80/0x80
    Code: 45 ac 0f 88 a8 01 00 00 3b b7 d0 01 00 00 49 89 ff 0f 83 99 01 00 00 48 8b 47 20 48 8b 80 88 00 00 00 48 85 c0 0f 84 cd 01 00 00 &lt;41&gt; 8b b1 5c 02 00 00 41 8b 89 58 02 00 00 89 75 98 41 8b b1 60
    RIP  [&lt;ffffffff8150423b&gt;] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320
     RSP &lt;ffff880234da7918&gt;
    CR2: 000000000000025c
    ---[ end trace ad2c0aadf48e2032 ]---
    Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009

It has helped me to add a NULL pointer check that was suggested at
http://lists.freedesktop.org/archives/dri-devel/2014-October/070663.html

I am not familiar with the code. But the change looks sane
and we need something fast at this stage of 3.18 development.

Suggested-by: Helge Deller &lt;deller@gmx.de&gt;
Signed-off-by: Petr Mladek &lt;pmladek@suse.cz&gt;
Tested-by: Petr Mladek &lt;pmladek@suse.cz&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: stable@vger.kernel.org
</content>
</entry>
<entry>
<title>drm/radeon: Ignore RADEON_GEM_GTT_WC on 32-bit x86</title>
<updated>2014-12-02T20:45:32Z</updated>
<author>
<name>Michel Dänzer</name>
<email>michel.daenzer@amd.com</email>
</author>
<published>2014-11-27T09:00:54Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=a08b588e4199e4200d26027ffcdf3ab2fa906412'/>
<id>urn:sha1:a08b588e4199e4200d26027ffcdf3ab2fa906412</id>
<content type='text'>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84627
Signed-off-by: Michel Dänzer &lt;michel.daenzer@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: stable@vger.kernel.org
</content>
</entry>
<entry>
<title>drm/radeon: sync all BOs involved in a CS v2</title>
<updated>2014-12-02T20:45:32Z</updated>
<author>
<name>Christian König</name>
<email>christian.koenig@amd.com</email>
</author>
<published>2014-11-27T12:12:58Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=86b276385c6a986872e4cd144f5940b156053c3f'/>
<id>urn:sha1:86b276385c6a986872e4cd144f5940b156053c3f</id>
<content type='text'>
Not just the userspace relocs, otherwise we won't wait
for a swapped out page tables to be swapped in again.

v2: rebased on Alex current drm-fixes-3.18

Signed-off-by: Christian König &lt;christian.koenig@amd.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
<entry>
<title>drm/i915: Unlock panel even when LVDS is disabled</title>
<updated>2014-12-02T13:18:29Z</updated>
<author>
<name>Daniel Vetter</name>
<email>daniel.vetter@ffwll.ch</email>
</author>
<published>2014-12-01T16:56:54Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=b0616c5306b342ceca07044dbc4f917d95c4f825'/>
<id>urn:sha1:b0616c5306b342ceca07044dbc4f917d95c4f825</id>
<content type='text'>
Otherwise we'll have backtraces in assert_panel_unlocked because the
BIOS locks the register. In the reporter's case this regression was
introduced in

commit c31407a3672aaebb4acddf90944a114fa5c8af7b
Author: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Date:   Thu Oct 18 21:07:01 2012 +0100

    drm/i915: Add no-lvds quirk for Supermicro X7SPA-H

Reported-by: Alexey Orishko &lt;alexey.orishko@gmail.com&gt;
Cc: Alexey Orishko &lt;alexey.orishko@gmail.com&gt;
Cc: stable@vger.kernel.org
Cc: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Cc: Francois Tigeot &lt;ftigeot@wolfpond.org&gt;
Signed-off-by: Daniel Vetter &lt;daniel.vetter@intel.com&gt;
Tested-by: Alexey Orishko &lt;alexey.orishko@gmail.com&gt;
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
</content>
</entry>
<entry>
<title>drm/i915: More cautious with pch fifo underruns</title>
<updated>2014-12-02T09:23:13Z</updated>
<author>
<name>Daniel Vetter</name>
<email>daniel.vetter@ffwll.ch</email>
</author>
<published>2014-11-24T16:02:45Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=b68362278af94e1171f5be9d4e44988601fb0439'/>
<id>urn:sha1:b68362278af94e1171f5be9d4e44988601fb0439</id>
<content type='text'>
Apparently PCH fifo underruns are tricky, we have plenty reports that
we see the occasional underrun (especially at boot-up).

So for a change let's see what happens when we don't re-enable pch
fifo underrun reporting when the pipe is disabled. This means that the
kernel can't catch pch fifo underruns when they happen (except when
all pipes are on on the pch). But we'll still catch underruns when
disabling the pipe again. So not a terrible reduction in test
coverage.

Since the DRM_ERROR is new and hence a regression plan B would be to
revert it back to a debug output. Which would be a lot worse than this
hack for underrun test coverage in the wild. See the referenced
discussions for more.

References: http://mid.gmane.org/CA+gsUGRfGe3t4NcjdeA=qXysrhLY3r4CEu7z4bjTwxi1uOfy+g@mail.gmail.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85898
References: https://bugs.freedesktop.org/show_bug.cgi?id=85898
References: https://bugs.freedesktop.org/show_bug.cgi?id=86233
References: https://bugs.freedesktop.org/show_bug.cgi?id=86478
Signed-off-by: Daniel Vetter &lt;daniel.vetter@intel.com&gt;
Tested-by: lu hua &lt;huax.lu@intel.com&gt;
Reviewed-by: Paulo Zanoni &lt;paulo.r.zanoni@intel.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
</content>
</entry>
<entry>
<title>nouveau: move the hotplug ignore to correct place.</title>
<updated>2014-12-02T06:27:25Z</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@redhat.com</email>
</author>
<published>2014-12-02T06:27:25Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=8b62c8c6df08ca567c78afa51aa7bbc554cede06'/>
<id>urn:sha1:8b62c8c6df08ca567c78afa51aa7bbc554cede06</id>
<content type='text'>
Introduced in b440bde74f, however it was added to
the wrong function in nouveau.

https://bugzilla.kernel.org/show_bug.cgi?id=86011
Cc: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
CC: stable@vger.kernel.org  # v3.15+
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
</content>
</entry>
<entry>
<title>Merge branch 'linux-3.18' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes</title>
<updated>2014-12-02T05:40:16Z</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@redhat.com</email>
</author>
<published>2014-12-02T05:40:16Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=d87c0e3d9f42cd3582498eac2d7409cc0361c0cb'/>
<id>urn:sha1:d87c0e3d9f42cd3582498eac2d7409cc0361c0cb</id>
<content type='text'>
Just a couple of fixes for the fallout from the fence rework.

* 'linux-3.18' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
  drm/nouveau/gf116: remove copy1 engine
  drm/nouveau: prevent stale fence-&gt;channel pointers, and protect with rcu
  drm/nouveau/fifo/g84-: ack non-stall interrupt before handling it
</content>
</entry>
<entry>
<title>drm/nouveau/gf116: remove copy1 engine</title>
<updated>2014-12-02T05:36:47Z</updated>
<author>
<name>Ilia Mirkin</name>
<email>imirkin@alum.mit.edu</email>
</author>
<published>2014-11-30T17:56:18Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=226d63a1addea8cbe8fc671978e62dc84927b046'/>
<id>urn:sha1:226d63a1addea8cbe8fc671978e62dc84927b046</id>
<content type='text'>
Indications are that no GF116's actually have a copy engine there, but
actually have the decompression engine. This engine can be made to do
copies, but that should be done separately.

Unclear why this didn't turn up on all GF116's, but perhaps the
non-mobile ones came with enough VRAM to not trigger ttm migrations in
test scenarios.

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=85465
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=59168
Cc: stable@vger.kernel.org
Signed-off-by: Ilia Mirkin &lt;imirkin@alum.mit.edu&gt;
Signed-off-by: Ben Skeggs &lt;bskeggs@redhat.com&gt;
</content>
</entry>
<entry>
<title>drm/nouveau: prevent stale fence-&gt;channel pointers, and protect with rcu</title>
<updated>2014-12-02T05:33:22Z</updated>
<author>
<name>Maarten Lankhorst</name>
<email>maarten.lankhorst@canonical.com</email>
</author>
<published>2014-12-01T09:11:06Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=0ec5f02f0e2c6fe88ba5817790e11fe33ee298a7'/>
<id>urn:sha1:0ec5f02f0e2c6fe88ba5817790e11fe33ee298a7</id>
<content type='text'>
Tested-by: Alexandre Courbot &lt;acourbot@nvidia.com&gt;
Signed-off-by: Ben Skeggs &lt;bskeggs@redhat.com&gt;
</content>
</entry>
</feed>
