summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm
AgeCommit message (Collapse)AuthorFilesLines
2017-05-19Merge tag 'drm-intel-fixes-2017-05-18-1' of ↵Dave Airlie8-18/+35
git://anongit.freedesktop.org/git/drm-intel into drm-fixes drm/i915 fixes for v4.12-rc2 * tag 'drm-intel-fixes-2017-05-18-1' of git://anongit.freedesktop.org/git/drm-intel: drm/i915: don't do allocate_va_range again on PIN_UPDATE drm/i915: Fix rawclk readout for g4x drm/i915: Fix runtime PM for LPE audio drm/i915/glk: Fix DSI "*ERROR* ULPS is still active" messages drm/i915/gvt: avoid unnecessary vgpu switch drm/i915/gvt: not to restore in-context mmio drm/i915/gvt: fix typo: "supporte" -> "support"
2017-05-19Merge branch 'linux-4.12' of git://github.com/skeggsb/linux into drm-fixesDave Airlie4-9/+10
misc nouveau fixes. * 'linux-4.12' of git://github.com/skeggsb/linux: drm/nouveau/fifo/gk104-: Silence a locking warning drm/nouveau/secboot: plug memory leak in ls_ucode_img_load_gr() error path drm/nouveau: Fix drm poll_helper handling
2017-05-19Merge tag 'drm-misc-fixes-2017-05-18' of ↵Dave Airlie1-22/+14
git://anongit.freedesktop.org/git/drm-misc into drm-fixes Driver Changes: - host1x: Fix link error when host1x is built-in and iova is a module (Arnd) - hlcdc: Fix arguments passed to drm_of_find_panel_or_bridge (Boris) Cc: Arnd Bergmann <arnd@arndb.de> Cc: Boris Brezillon <boris.brezillon@free-electrons.com> * tag 'drm-misc-fixes-2017-05-18' of git://anongit.freedesktop.org/git/drm-misc: drm/atmel-hlcdc: Fix output initialization gpu: host1x: select IOMMU_IOVA
2017-05-19Merge branch 'etnaviv/fixes' of https://git.pengutronix.de/git/lst/linux ↵Dave Airlie1-1/+3
into drm-fixes one etnaviv fence leak fix. * 'etnaviv/fixes' of https://git.pengutronix.de/git/lst/linux: drm/etnaviv: don't put fence in case of submit failure
2017-05-18drm/atmel-hlcdc: Fix output initializationBoris Brezillon1-22/+14
drm_of_find_panel_or_bridge() is expecting np to point to the encoder node, not the bridge or panel this encoder is feeding. Moreover, the endpoint parameter passed to drm_of_find_panel_or_bridge() is always set to zero, which prevents us from probing all outputs. We also move the atmel_hlcdc_rgb_output allocation after the panel/bridge detection to avoid useless allocations. Reported-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Fixes: ebc944613567 ("drm: convert drivers to use drm_of_find_panel_or_bridge") Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Tested-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/1495110921-4032-1-git-send-email-boris.brezillon@free-electrons.com
2017-05-18drm/i915: Fix new -Wint-in-bool-context gcc compiler warningHans de Goede1-1/+1
This commit fixes the following compiler warning: drivers/gpu/drm/i915/intel_dsi.c: In function ‘intel_dsi_prepare’: drivers/gpu/drm/i915/intel_dsi.c:1487:23: warning: ?: using integer constants in boolean context [-Wint-in-bool-context] PORT_A ? PORT_C : PORT_A), Fixes: f4c3a88e5f04 ("drm/i915: Tighten mmio arrays for MIPI_PORT") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170518110644.9902-1-hdegoede@redhat.com (cherry picked from commit 0ad4dc887d4168448e8c801aa4edd8fe1e0bd534) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2017-05-18drm/i915: use vma->size for appgtt allocate_va_rangeMatthew Auld1-1/+1
For the aliasing ppgtt we clear the va range up to vma->size, but seem to allocate up to vma->node.size, which is a little inconsistent given that vma->node.size >= vma->size. Not that is really matters all that much since we preallocate anyway, but for consistency just use vma->size. Fixes: ff685975d97f ("drm/i915: Move allocate_va_range to GTT") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170516085514.5853-1-matthew.auld@intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (cherry picked from commit d567232cbd9ec2a289ddffea4013b7265bbcc3d5) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2017-05-18drm/i915: Do not sync RCU during shrinkingJoonas Lahtinen1-5/+0
Due to the complex dependencies between workqueues and RCU, which are not easily detected by lockdep, do not synchronize RCU during shrinking. On low-on-memory systems (mem=1G for example), the RCU sync leads to all system workqueus freezing and unrelated lockdep splats are displayed according to reports. GIT bisecting done by J. R. Okajima points to the commit where RCU syncing was extended. RCU sync gains us very little benefit in real life scenarios where the amount of memory used by object backing storage is dominant over the metadata under RCU, so drop it altogether. " Yeeeaah, if core could just, go ahead and reclaim RCU queues, that'd be great. " - Chris Wilson, 2016 (0eafec6d3244) v2: More information to commit message. v3: Remove "grep _rcu_" escapee from i915_gem_shrink_all (Andrea) Fixes: c053b5a506d3 ("drm/i915: Don't call synchronize_rcu_expedited under struct_mutex") Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Reported-by: J. R. Okajima <hooanon05g@gmail.com> Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Hugh Dickins <hughd@google.com> Tested-by: Andrea Arcangeli <aarcange@redhat.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: J. R. Okajima <hooanon05g@gmail.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Hugh Dickins <hughd@google.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: <stable@vger.kernel.org> # v4.11+ (cherry picked from commit 73cc0b9aa9afa5ba65d92e46ded61d29430d72a4) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1495097379-573-1-git-send-email-joonas.lahtinen@linux.intel.com
2017-05-17drm/nouveau/fifo/gk104-: Silence a locking warningDan Carpenter1-1/+2
Presumably we can never actually hit this return, but static checkers complain that we should unlock before we return. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-05-17drm/nouveau/secboot: plug memory leak in ls_ucode_img_load_gr() error pathChristophe JAILLET1-1/+3
The last goto looks spurious because it releases less resources than the previous one. Also free 'img->sig' if 'ls_ucode_img_build()' fails. Fixes: 9d896f3e41a6 ("drm/nouveau/secboot: abstract LS firmware loading functions") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-05-17drm/nouveau: Fix drm poll_helper handlingPeter Ujfalusi2-7/+5
Commit cae9ff036eea effectively disabled the drm poll_helper by checking the wrong flag to see if the driver should enable the poll or not: mode_config.poll_enabled is only set to true by poll_init and it is not indicating if the poll is enabled or not. nouveau_display_create() will initialize the poll and going to disable it right away. After poll_init() the mode_config.poll_enabled will be true, but the poll itself is disabled. To avoid the race caused by calling the poll_enable() from different paths, this patch will enable the poll from one place, in the nouveau_display_hpd_work(). In case the pm_runtime is disabled we will enable the poll in nouveau_drm_load() once. Fixes: cae9ff036eea ("drm/nouveau: Don't enabling polling twice on runtime resume") Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Reviewed-by: Lyude <lyude@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-05-15drm/i915: don't do allocate_va_range again on PIN_UPDATEMatthew Auld1-4/+8
If a vma is already bound to a ppgtt, we incorrectly call allocate_va_range again when doing a PIN_UPDATE, which will result in over accounting within our paging structures, such that when we do unbind something we don't actually destroy the structures and end up inadvertently recycling them. In reality this probably isn't too bad, but once we start touching PDEs and PDPEs for 64K/2M/1G pages this apparent recycling will manifest into lots of really, really subtle bugs. v2: Fix the testing of vma->flags for aliasing_ppgtt_bind_vma Fixes: ff685975d97f ("drm/i915: Move allocate_va_range to GTT") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170512091423.26085-1-chris@chris-wilson.co.uk (cherry picked from commit 1f23475c893a85c934143cd64865ebb9b6af383f) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2017-05-15drm/i915: Fix rawclk readout for g4xVille Syrjälä2-7/+9
Turns out our skills in decoding the CLKCFG register weren't good enough. On this particular elk the answer we got was 400 MHz when in reality the clock was running at 266 MHz, which then caused us to program a bogus AUX clock divider that caused all AUX communication to fail. Sadly the docs are now in bit heaven, so the fix will have to be based on empirical evidence. Using another elk machine I was able to frob the FSB frequency from the BIOS and see how it affects the CLKCFG register. The machine seesm to use a frequency of 266 MHz by default, and fortunately it still boot even with the 50% CPU overclock that we get when we bump the FSB up to 400 MHz. It turns out the actual FSB frequency and the register have no real link whatsoever. The register value is based on some straps or something, but fortunately those too can be configured from the BIOS on this board, although it doesn't seem to respect the settings 100%. In the end I was able to derive the following relationship: BIOS FSB / strap | CLKCFG ------------------------- 200 | 0x2 266 | 0x0 333 | 0x4 400 | 0x4 So only the 200 and 400 MHz cases actually match how we're currently decoding that register. But as the comment next to some of the defines says, we have been just guessing anyway. So let's fix things up so that at least the 266 MHz case will work correctly as that is actually the setting used by both the buggy machine and my test machine. The fact that 333 and 400 MHz BIOS settings result in the same register value is a little disappointing, as that means we can't tell them apart. However, according to the gmch datasheet for both elk and ctg 400 Mhz is not even a supported FSB frequency, so I'm going to make the assumption that we should decode it as 333 MHz instead. Cc: stable@vger.kernel.org Cc: Tomi Sarvela <tomi.p.sarvela@intel.com> Reported-by: Tomi Sarvela <tomi.p.sarvela@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100926 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170504181530.6908-1-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com> Tested-by: Tomi Sarvela <tomi.p.sarvela@intel.com> (cherry picked from commit 6f38123ecaac446312a63523b68df84ceb5a06ed) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2017-05-15drm/i915: Fix runtime PM for LPE audioVille Syrjälä1-0/+5
Not calling pm_runtime_enable() means that runtime PM can't be enabled at all via sysfs. So we definitely need to call it from somewhere. Calling it from the driver seems like a bad idea because it would have to be paired with a pm_runtime_disable() at driver unload time, otherwise the core gets upset. Also if there's no LPE audio driver loaded then we couldn't runtime suspend i915 either. So it looks like a better plan is to call it from i915 when we register the platform device. That seems to match how pci generally does things. I cargo culted the pm_runtime_forbid() and pm_runtime_set_active() calls from pci as well. The exposed runtime PM API is massive an thorougly misleading, so I don't actually know if this is how you're supposed to use the API or not. But it seems to work. I can now runtime suspend i915 again with or without the LPE audio driver loaded, and reloading the LPE audio driver also seems to work. Note that powertop won't auto-tune runtime PM for platform devices, which is a little annoying. So I'm not sure that leaving runtime PM in "on" mode by default is the best choice here. But I've left it like that for now at least. Also remove the comment about there not being much benefit from LPE audio runtime PM. Not allowing runtime PM blocks i915 runtime PM, which will also block s0ix, and that could have a measurable impact on power consumption. Cc: stable@vger.kernel.org Cc: Takashi Iwai <tiwai@suse.de> Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Fixes: 0b6b524f3915 ("ALSA: x86: Don't enable runtime PM as default") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170427160231.13337-2-ville.syrjala@linux.intel.com Reviewed-by: Takashi Iwai <tiwai@suse.de> (cherry picked from commit 183c00350ccda86781f6695840e6c5f5b22efbd1) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2017-05-15drm/i915/glk: Fix DSI "*ERROR* ULPS is still active" messagesAnder Conselvan de Oliveira1-4/+3
The sequence in glk_dsi_device_ready() enters ULPS then waits until it is *not* active to then disable it. The correct sequence according to the spec is to enter ULPS then wait until the GLK_ULPS_NOT_ACTIVE bit is zero, i.e., ULPS is active, and then disable ULPS. Fixing the condition gets rid of the following spurious error messages: [drm:glk_dsi_device_ready [i915]] *ERROR* ULPS is still active Fixes: 4644848369c0 ("drm/i915/glk: Add MIPIIO Enable/disable sequence") Cc: Deepak M <m.deepak@intel.com> Cc: Madhav Chauhan <madhav.chauhan@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Cc: <drm-intel-fixes@lists.freedesktop.org> Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Madhav Chauhan <madhav.chauhan@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170428080222.6147-1-ander.conselvan.de.oliveira@intel.com (cherry picked from commit 3acbec03b3c51559d01c879e9564d9c9610fe8ce) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2017-05-15Merge tag 'gvt-fixes-2017-05-11' of https://github.com/01org/gvt-linux into ↵Jani Nikula3-3/+10
drm-intel-fixes gvt-fixes-2017-05-11 - vGPU scheduler performance regression fix (Ping) - bypass in-context mmio restore (Chuanxiao) - one typo fix (Colin) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170511054736.swpcmnzdoqi75cnl@zhen-hp.sh.intel.com
2017-05-12drm/i915: Make vblank evade warnings optionalVille Syrjälä2-2/+18
Add a new Kconfig option to enable/disable the extra warnings from the vblank evade code. For now we'll keep the warning about an actually missed vblank always enabled as that can have an actual user visible impact. But if we miss the deadline othrwise there's no real need to bother the user with that. We'll want these warnings enabled during development however so that we can catch regressions. Based on the reports it looks like this is still very easy to hit on SKL, so we have more work ahead of us to optimize the crtiical section further. Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Jens Axboe <axboe@kernel.dk> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reported-by: Jens Axboe <axboe@kernel.dk> Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Fixes: e1edbd44e23b ("drm/i915: Complain if we take too long under vblank evasion.") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2017-05-12Merge branch 'linux-4.12' of git://github.com/skeggsb/linux into drm-nextDave Airlie9-41/+60
Quite a few patches, but not much code changed: - Fixes regression from atomic when only the source rect of a plane changes (ie. xrandr --right-of) - Fixes another issue where atomic changed behaviour underneath us, potentially causing laggy cursor position updates - Fixes for a bunch of races in thermal code, which lead to random lockups for a lot of users * 'linux-4.12' of git://github.com/skeggsb/linux: drm/nouveau/therm: remove ineffective workarounds for alarm bugs drm/nouveau/tmr: avoid processing completed alarms when adding a new one drm/nouveau/tmr: fix corruption of the pending list when rescheduling an alarm drm/nouveau/tmr: handle races with hw when updating the next alarm time drm/nouveau/tmr: ack interrupt before processing alarms drm/nouveau/core: fix static checker warning drm/nouveau/fb/ram/gf100-: remove 0x10f200 read drm/nouveau/kms/nv50: skip core channel cursor update on position-only changes drm/nouveau/kms/nv50: fix source-rect-only plane updates drm/nouveau/kms/nv50: remove pointless argument to window atomic_check_acquire()
2017-05-12Merge branch 'drm-next-4.12' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie95-2076/+2322
into drm-next Fixes for 4.12. This is a bit bigger than usual since it's 3 weeks worth of fixes and most of these changes are for vega10 which is new for 4.12 and still in a fair amount of flux. It looks like you missed my last pull request, so those patches are included here as well. Highlights: - Lots of vega10 fixes - Fix interruptable wait mixup - Fan control method fixes - Misc display fixes for radeon and amdgpu - Misc bug fixes * 'drm-next-4.12' of git://people.freedesktop.org/~agd5f/linux: (132 commits) drm/amd/powerplay: refine pwm1_enable callback functions for CI. drm/amd/powerplay: refine pwm1_enable callback functions for vi. drm/amd/powerplay: refine pwm1_enable callback functions for Vega10. drm/amdgpu: refine amdgpu pwm1_enable sysfs interface. drm/amdgpu: add amd fan ctrl mode enums. drm/amd/powerplay: add more smu message on Vega10. drm/amdgpu: fix dependency issue drm/amd: fix init order of sched job drm/amdgpu: add some additional vega10 pci ids drm/amdgpu/soc15: use atomfirmware for setting bios scratch for reset drm/amdgpu/atomfirmware: add function to update engine hang status drm/radeon: only warn once in radeon_ttm_bo_destroy if va list not empty drm/amdgpu: fix mutex list null pointer reference drm/amd/powerplay: fix bug sclk/mclk level can't be set on vega10. drm/amd/powerplay: Setup sw CTF to allow graceful exit when temperature exceeds maximum. drm/amd/powerplay: delete dead code in powerplay. drm/amdgpu: Use less generic enum definitions drm/amdgpu/gfx9: derive tile pipes from golden settings drm/amdgpu/gfx: drop max_gs_waves_per_vgt drm/amd/powerplay: disable engine spread spectrum feature on Vega10. ...
2017-05-12Merge tag 'drm-misc-next-fixes-2017-05-05' of ↵Dave Airlie1-0/+8
git://anongit.freedesktop.org/git/drm-misc into drm-next Core Changes: - Add quirk for LGD 764 panel to default 10bpc (Mario) Cc: Mario Kleiner <mario.kleiner.de@gmail.com> * tag 'drm-misc-next-fixes-2017-05-05' of git://anongit.freedesktop.org/git/drm-misc: drm/edid: Add 10 bpc quirk for LGD 764 panel in HP zBook 17 G2
2017-05-12drm/nouveau/therm: remove ineffective workarounds for alarm bugsBen Skeggs4-4/+4
These were ineffective due to touching the list without the alarm lock, but should no longer be required. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org
2017-05-12drm/nouveau/tmr: avoid processing completed alarms when adding a new oneBen Skeggs1-3/+13
The idea here was to avoid having to "manually" program the HW if there's a new earliest alarm. This was lazy and bad, as it leads to loads of fun races between inter-related callers (ie. therm). Turns out, it's not so difficult after all. Go figure ;) Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org
2017-05-12drm/nouveau/tmr: fix corruption of the pending list when rescheduling an alarmBen Skeggs1-7/+10
At least therm/fantog "attempts" to work around this issue, which could lead to corruption of the pending alarm list. Fix it properly by not updating the timestamp without the lock held, or trying to add an already pending alarm to the pending alarm list.... Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org
2017-05-12drm/nouveau/tmr: handle races with hw when updating the next alarm timeBen Skeggs1-10/+16
If the time to the next alarm is short enough, we could race with HW and end up with an ~4 second delay until it triggers. Fix this by checking again after we update HW. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org
2017-05-12drm/nouveau/tmr: ack interrupt before processing alarmsBen Skeggs1-1/+1
Fixes a race where we can miss an alarm that triggers while we're already processing previous alarms. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org
2017-05-12drm/nouveau/core: fix static checker warningBen Skeggs1-1/+1
object->engine cannot be NULL, it's either valid, or an error pointer. This particular condition shouldn't actually be possible, but just in case, we'll keep it. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-05-12drm/nouveau/fb/ram/gf100-: remove 0x10f200 readBen Skeggs1-1/+0
This reg has moved on Pascal, and causes a bus fault. We never use the value anyway, so just remove the read. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-05-12drm/nouveau/kms/nv50: skip core channel cursor update on position-only changesBen Skeggs1-3/+7
The DRM core used to only call prepare_fb/cleanup_fb() when a plane's framebuffer changed, which achieved the desired effect. It's apparently now up to the driver to decide on its own. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org [4.11+]
2017-05-12drm/nouveau/kms/nv50: fix source-rect-only plane updatesBen Skeggs1-5/+3
This "optimisation" (which was originally meant to skip updating cursor settings in the core channel on position-only updates) turned out to be pointless in the final design of the code before it was merged. Remove it completely, as it breaks other cases. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org [4.10+]
2017-05-12drm/nouveau/kms/nv50: remove pointless argument to window atomic_check_acquire()Ben Skeggs1-7/+6
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-05-10Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhostLinus Torvalds1-2/+1
Pull virtio updates from Michael Tsirkin: "Fixes, cleanups, performance A bunch of changes to virtio, most affecting virtio net. Also ptr_ring batched zeroing - first of batching enhancements that seems ready." * tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost: s390/virtio: change maintainership tools/virtio: fix spelling mistake: "wakeus" -> "wakeups" virtio_net: tidy a couple debug statements ptr_ring: support testing different batching sizes ringtest: support test specific parameters ptr_ring: batch ring zeroing virtio: virtio_driver doc virtio_net: don't reset twice on XDP on/off virtio_net: fix support for small rings virtio_net: reduce alignment for buffers virtio_net: rework mergeable buffer handling virtio_net: allow specifying context for rx virtio: allow extra context per descriptor tools/virtio: fix build breakage virtio: add context flag to find vqs virtio: wrap find_vqs ringtest: fix an assert statement
2017-05-10drm/amd/powerplay: refine pwm1_enable callback functions for CI.Rex Zhu1-12/+15
Use the new enums for setting and getting the fan control mode. Fixes problems due to previous inconsistencies between enums. Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2017-05-10drm/amd/powerplay: refine pwm1_enable callback functions for vi.Rex Zhu4-20/+27
Use the new enums for setting and getting the fan control mode. Fixes problems due to previous inconsistencies between enums. Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2017-05-10drm/amd/powerplay: refine pwm1_enable callback functions for Vega10.Rex Zhu2-20/+25
Use the new enums for setting and getting the fan control mode. Fixes problems due to previous inconsistencies between enums. Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2017-05-10drm/amdgpu: refine amdgpu pwm1_enable sysfs interface.Rex Zhu1-10/+2
Make the interface consistent. Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2017-05-10drm/amdgpu: add amd fan ctrl mode enums.Rex Zhu1-0/+6
Add common fan enums that can be used for both powerplay and dpm. Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2017-05-10drm/amd/powerplay: add more smu message on Vega10.Rex Zhu1-1/+4
Add some new SMU messages. Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2017-05-10Merge branch 'core-rcu-for-linus' of ↵Linus Torvalds3-3/+3
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull RCU updates from Ingo Molnar: "The main changes are: - Debloat RCU headers - Parallelize SRCU callback handling (plus overlapping patches) - Improve the performance of Tree SRCU on a CPU-hotplug stress test - Documentation updates - Miscellaneous fixes" * 'core-rcu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (74 commits) rcu: Open-code the rcu_cblist_n_lazy_cbs() function rcu: Open-code the rcu_cblist_n_cbs() function rcu: Open-code the rcu_cblist_empty() function rcu: Separately compile large rcu_segcblist functions srcu: Debloat the <linux/rcu_segcblist.h> header srcu: Adjust default auto-expediting holdoff srcu: Specify auto-expedite holdoff time srcu: Expedite first synchronize_srcu() when idle srcu: Expedited grace periods with reduced memory contention srcu: Make rcutorture writer stalls print SRCU GP state srcu: Exact tracking of srcu_data structures containing callbacks srcu: Make SRCU be built by default srcu: Fix Kconfig botch when SRCU not selected rcu: Make non-preemptive schedule be Tasks RCU quiescent state srcu: Expedite srcu_schedule_cbs_snp() callback invocation srcu: Parallelize callback handling kvm: Move srcu_struct fields to end of struct kvm rcu: Fix typo in PER_RCU_NODE_PERIOD header comment rcu: Use true/false in assignment to bool rcu: Use bool value directly ...
2017-05-10drm/amdgpu: fix dependency issueChunming Zhou6-1/+27
The problem is that executing the jobs in the right order doesn't give you the right result because consecutive jobs executed on the same engine are pipelined. In other words job B does it buffer read before job A has written it's result. Signed-off-by: Chunming Zhou <David1.Zhou@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2017-05-10drm/amd: fix init order of sched jobChunming Zhou1-1/+1
Need to increment after the fence check. Signed-off-by: Chunming Zhou <David1.Zhou@amd.com> Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2017-05-10drm/amdgpu: add some additional vega10 pci idsAlex Deucher1-0/+2
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2017-05-10drm/amdgpu/soc15: use atomfirmware for setting bios scratch for resetAlex Deucher1-3/+3
Need to use the atomfirmware interface rather than atombios since soc15 is atomfirmware based. Reviewed-by: Chunming Zhou <david1.zhou@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2017-05-10drm/amdgpu/atomfirmware: add function to update engine hang statusAlex Deucher2-0/+15
Update the scratch reg for when the engine is hung. Reviewed-by: Chunming Zhou <david1.zhou@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2017-05-10drm/radeon: only warn once in radeon_ttm_bo_destroy if va list not emptyJulien Isorce1-1/+1
Encountered a dozen of exact same backtraces when mesa's pb_cache_release_all_buffers is called after that a gpu reset failed. v2: Remove superfluous error message added in v1. bug: https://bugs.freedesktop.org/show_bug.cgi?id=96271 Signed-off-by: Julien Isorce <jisorce@oblong.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2017-05-10drm/i915/gvt: avoid unnecessary vgpu switchPing Gao1-2/+6
It's no need to switch vgpu if next vgpu is the same with current vgpu, otherwise it will make performance drop in some case. v2: correct the comments. Signed-off-by: Ping Gao <ping.a.gao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2017-05-08format-security: move static strings to constKees Cook1-1/+1
While examining output from trial builds with -Wformat-security enabled, many strings were found that should be defined as "const", or as a char array instead of char pointer. This makes some static analysis easier, by producing fewer false positives. As these are all trivial changes, it seemed best to put them all in a single patch rather than chopping them up per maintainer. Link: http://lkml.kernel.org/r/20170405214711.GA5711@beast Signed-off-by: Kees Cook <keescook@chromium.org> Acked-by: Jes Sorensen <jes@trained-monkey.org> [runner.c] Cc: Tony Lindgren <tony@atomide.com> Cc: Russell King <linux@armlinux.org.uk> Cc: "Maciej W. Rozycki" <macro@linux-mips.org> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: Viresh Kumar <viresh.kumar@linaro.org> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: David Airlie <airlied@linux.ie> Cc: Yisen Zhuang <yisen.zhuang@huawei.com> Cc: Salil Mehta <salil.mehta@huawei.com> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Jiri Slaby <jslaby@suse.com> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: James Hogan <james.hogan@imgtec.com> Cc: Paul Burton <paul.burton@imgtec.com> Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk> Cc: Mugunthan V N <mugunthanvnm@ti.com> Cc: Felipe Balbi <felipe.balbi@linux.intel.com> Cc: Jarod Wilson <jarod@redhat.com> Cc: Florian Westphal <fw@strlen.de> Cc: Antonio Quartulli <a@unstable.cc> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: Kejian Yan <yankejian@huawei.com> Cc: Daode Huang <huangdaode@hisilicon.com> Cc: Qianqian Xie <xieqianqian@huawei.com> Cc: Philippe Reynes <tremyfr@gmail.com> Cc: Colin Ian King <colin.king@canonical.com> Cc: Eric Dumazet <edumazet@google.com> Cc: Christian Gromm <christian.gromm@microchip.com> Cc: Andrey Shvetsov <andrey.shvetsov@k2l.de> Cc: Jason Litzinger <jlitzingerdev@gmail.com> Cc: WANG Cong <xiyou.wangcong@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-05-08drm: use set_memory.h headerLaura Abbott8-0/+19
set_memory_* functions have moved to set_memory.h. Switch to this explicitly. [akpm@linux-foundation.org: track drivers/gpu/drm/i915/i915_gem_gtt.c linux-next changes] Link: http://lkml.kernel.org/r/1488920133-27229-8-git-send-email-labbott@redhat.com Signed-off-by: Laura Abbott <labbott@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-05-08mm, vmalloc: use __GFP_HIGHMEM implicitlyMichal Hocko1-2/+2
__vmalloc* allows users to provide gfp flags for the underlying allocation. This API is quite popular $ git grep "=[[:space:]]__vmalloc\|return[[:space:]]*__vmalloc" | wc -l 77 The only problem is that many people are not aware that they really want to give __GFP_HIGHMEM along with other flags because there is really no reason to consume precious lowmemory on CONFIG_HIGHMEM systems for pages which are mapped to the kernel vmalloc space. About half of users don't use this flag, though. This signals that we make the API unnecessarily too complex. This patch simply uses __GFP_HIGHMEM implicitly when allocating pages to be mapped to the vmalloc space. Current users which add __GFP_HIGHMEM are simplified and drop the flag. Link: http://lkml.kernel.org/r/20170307141020.29107-1-mhocko@kernel.org Signed-off-by: Michal Hocko <mhocko@suse.com> Reviewed-by: Matthew Wilcox <mawilcox@microsoft.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: David Rientjes <rientjes@google.com> Cc: Cristopher Lameter <cl@linux.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-05-08treewide: use kv[mz]alloc* rather than opencoded variantsMichal Hocko1-3/+1
There are many code paths opencoding kvmalloc. Let's use the helper instead. The main difference to kvmalloc is that those users are usually not considering all the aspects of the memory allocator. E.g. allocation requests <= 32kB (with 4kB pages) are basically never failing and invoke OOM killer to satisfy the allocation. This sounds too disruptive for something that has a reasonable fallback - the vmalloc. On the other hand those requests might fallback to vmalloc even when the memory allocator would succeed after several more reclaim/compaction attempts previously. There is no guarantee something like that happens though. This patch converts many of those places to kv[mz]alloc* helpers because they are more conservative. Link: http://lkml.kernel.org/r/20170306103327.2766-2-mhocko@kernel.org Signed-off-by: Michal Hocko <mhocko@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> # Xen bits Acked-by: Kees Cook <keescook@chromium.org> Acked-by: Vlastimil Babka <vbabka@suse.cz> Acked-by: Andreas Dilger <andreas.dilger@intel.com> # Lustre Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> # KVM/s390 Acked-by: Dan Williams <dan.j.williams@intel.com> # nvdim Acked-by: David Sterba <dsterba@suse.com> # btrfs Acked-by: Ilya Dryomov <idryomov@gmail.com> # Ceph Acked-by: Tariq Toukan <tariqt@mellanox.com> # mlx4 Acked-by: Leon Romanovsky <leonro@mellanox.com> # mlx5 Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Anton Vorontsov <anton@enomsg.org> Cc: Colin Cross <ccross@android.com> Cc: Tony Luck <tony.luck@intel.com> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Kent Overstreet <kent.overstreet@gmail.com> Cc: Santosh Raspatur <santosh@chelsio.com> Cc: Hariprasad S <hariprasad@chelsio.com> Cc: Yishai Hadas <yishaih@mellanox.com> Cc: Oleg Drokin <oleg.drokin@intel.com> Cc: "Yan, Zheng" <zyan@redhat.com> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: David Miller <davem@davemloft.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-05-08drm/i915/gvt: not to restore in-context mmioChuanxiao Dong1-0/+3
Needn't to restore the in-context MMIO when SCHEDULE_OUT. Sometimes with restoring the in-context MMIO, some GPU hang can be observed. So remove the in-context MMIO restore Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-28 22:02:36 +0000