summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2016-05-27remove lots of IS_ERR_VALUE abusesArnd Bergmann3-4/+4
Most users of IS_ERR_VALUE() in the kernel are wrong, as they pass an 'int' into a function that takes an 'unsigned long' argument. This happens to work because the type is sign-extended on 64-bit architectures before it gets converted into an unsigned type. However, anything that passes an 'unsigned short' or 'unsigned int' argument into IS_ERR_VALUE() is guaranteed to be broken, as are 8-bit integers and types that are wider than 'unsigned long'. Andrzej Hajda has already fixed a lot of the worst abusers that were causing actual bugs, but it would be nice to prevent any users that are not passing 'unsigned long' arguments. This patch changes all users of IS_ERR_VALUE() that I could find on 32-bit ARM randconfig builds and x86 allmodconfig. For the moment, this doesn't change the definition of IS_ERR_VALUE() because there are probably still architecture specific users elsewhere. Almost all the warnings I got are for files that are better off using 'if (err)' or 'if (err < 0)'. The only legitimate user I could find that we get a warning for is the (32-bit only) freescale fman driver, so I did not remove the IS_ERR_VALUE() there but changed the type to 'unsigned long'. For 9pfs, I just worked around one user whose calling conventions are so obscure that I did not dare change the behavior. I was using this definition for testing: #define IS_ERR_VALUE(x) ((unsigned long*)NULL == (typeof (x)*)NULL && \ unlikely((unsigned long long)(x) >= (unsigned long long)(typeof(x))-MAX_ERRNO)) which ends up making all 16-bit or wider types work correctly with the most plausible interpretation of what IS_ERR_VALUE() was supposed to return according to its users, but also causes a compile-time warning for any users that do not pass an 'unsigned long' argument. I suggested this approach earlier this year, but back then we ended up deciding to just fix the users that are obviously broken. After the initial warning that caused me to get involved in the discussion (fs/gfs2/dir.c) showed up again in the mainline kernel, Linus asked me to send the whole thing again. [ Updated the 9p parts as per Al Viro - Linus ] Signed-off-by: Arnd Bergmann <arnd@arndb.de> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Andrew Morton <akpm@linux-foundation.org> Link: https://lkml.org/lkml/2016/1/7/363 Link: https://lkml.org/lkml/2016/5/27/486 Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> # For nvmem part Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-05-27Merge tag 'drm-fixes-v4.7-rc1' of git://people.freedesktop.org/~airlied/linuxLinus Torvalds48-492/+1044
Pull drm fixes from Dave Airlie: - one IMX built-in regression fix - a set of amdgpu fixes, mostly powerplay and polaris GPU stuff - a set of i915 fixes all over, many cc'ed to stable. The i915 batch contain support for DP++ dongle detection, which is used to fix some regressions in the HDMI color depth area * tag 'drm-fixes-v4.7-rc1' of git://people.freedesktop.org/~airlied/linux: (44 commits) drm/amd: add Kconfig dependency for ACP on DRM_AMDGPU drm/amdgpu: Fix hdmi deep color support. drm/amdgpu: fix bug in fence driver fini drm/i915: Stop automatically retiring requests after a GPU hang drm/i915: Unify intel_ring_begin() drm/i915: Ignore stale wm register values on resume on ilk-bdw (v2) drm/i915/psr: Try to program link training times correctly drm/imx: Match imx-ipuv3-crtc components using device node in platform data drm/i915/bxt: Adjusting the error in horizontal timings retrieval drm/i915: Don't leave old junk in ilk active watermarks on readout drm/i915: s/DPPL/DPLL/ for SKL DPLLs drm/i915: Fix gen8 semaphores id for legacy mode drm/i915: Set crtc_state->lane_count for HDMI drm/i915/BXT: Retrieving the horizontal timing for DSI drm/i915: Protect gen7 irq_seqno_barrier with uncore lock drm/i915: Re-enable GGTT earlier during resume on pre-gen6 platforms drm/i915: Determine DP++ type 1 DVI adaptor presence based on VBT drm/i915: Enable/disable TMDS output buffers in DP++ adaptor as needed drm/i915: Respect DP++ adaptor TMDS clock limit drm: Add helper for DP++ adaptors ...
2016-05-27Merge tag 'drm-intel-next-fixes-2016-05-25' of ↵Dave Airlie23-307/+849
git://anongit.freedesktop.org/drm-intel into drm-next I see the main drm pull got merged, here's the first batch of fixes for 4.7 already. Fixes all around, a large portion cc: stable stuff. [airlied: the DP++ stuff is a regression fix]. * tag 'drm-intel-next-fixes-2016-05-25' of git://anongit.freedesktop.org/drm-intel: drm/i915: Stop automatically retiring requests after a GPU hang drm/i915: Unify intel_ring_begin() drm/i915: Ignore stale wm register values on resume on ilk-bdw (v2) drm/i915/psr: Try to program link training times correctly drm/i915/bxt: Adjusting the error in horizontal timings retrieval drm/i915: Don't leave old junk in ilk active watermarks on readout drm/i915: s/DPPL/DPLL/ for SKL DPLLs drm/i915: Fix gen8 semaphores id for legacy mode drm/i915: Set crtc_state->lane_count for HDMI drm/i915/BXT: Retrieving the horizontal timing for DSI drm/i915: Protect gen7 irq_seqno_barrier with uncore lock drm/i915: Re-enable GGTT earlier during resume on pre-gen6 platforms drm/i915: Determine DP++ type 1 DVI adaptor presence based on VBT drm/i915: Enable/disable TMDS output buffers in DP++ adaptor as needed drm/i915: Respect DP++ adaptor TMDS clock limit drm: Add helper for DP++ adaptors
2016-05-27Merge branch 'drm-next-4.7' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie22-182/+183
into drm-next AMD GPU bugfixes: - Various powerplay bug fixes - Add some new polaris pci ids - misc bug fixes and code cleanups * 'drm-next-4.7' of git://people.freedesktop.org/~agd5f/linux: (27 commits) drm/amd: add Kconfig dependency for ACP on DRM_AMDGPU drm/amdgpu: Fix hdmi deep color support. drm/amdgpu: fix bug in fence driver fini drm/amd/powerplay/hwmgr: use kmemdup drm/amd/powerplay/hwmgr: use kmemdup drm/amd/powerplay/hwmgr: use kmemdup drm/amd/powerplay: fix bugs of checking if dpm is running on Tonga drm/amdgpu: update Polaris11 golden setting drm/amdgpu: Add more Polaris 11 PCI IDs drm/amdgpu: update Polaris10 golden setting drm/amdgpu: add more Polaris10 DID drm/amd/amdgpu : Remove unused variable drm/amd/amdgpu : Remove unused variable drm/amd/amdgpu : Remove unused variable drm/amd/amdgpu/cz_dpm: Remove unused variable drm/amd/amdgpu : Remove unused variable drm/amd/powerplay: use ARRAY_SIZE() to calculate array size. drm/amdgpu: fix array out of bounds drm/radeon: fix array out of bounds drm/amd/powerplay: fix a bug on updating sclk for Tonga ...
2016-05-25Merge tag 'pwm/for-4.7-rc1' of ↵Linus Torvalds1-0/+6
git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm Pull pwm updates from Thierry Reding: "This set of changes introduces an atomic API to the PWM subsystem. This is influenced by the DRM atomic API that was introduced a while back, though it is obviously a lot simpler. The fundamental idea remains the same, though: drivers provide a single callback to implement the atomic configuration of a PWM channel. As a side-effect the PWM subsystem gains the ability for initial state retrieval, so that the logical state mirrors that of the hardware. Many use-cases don't care about this, but for others it is essential. These new features require changes in all users, which these patches take care of. The core is transitioned to use the atomic callback if available and provides a fallback mechanism for other drivers. Changes to transition users and drivers to the atomic API are postponed to v4.8" * tag 'pwm/for-4.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: (30 commits) pwm: Add information about polarity, duty cycle and period to debugfs pwm: Switch to the atomic API pwm: Update documentation pwm: Add core infrastructure to allow atomic updates pwm: Add hardware readout infrastructure pwm: Move the enabled/disabled info into pwm_state pwm: Introduce the pwm_state concept pwm: Keep PWM state in sync with hardware state ARM: Explicitly apply PWM config extracted from pwm_args drm: i915: Explicitly apply PWM config extracted from pwm_args input: misc: pwm-beeper: Explicitly apply PWM config extracted from pwm_args input: misc: max8997: Explicitly apply PWM config extracted from pwm_args backlight: lm3630a: explicitly apply PWM config extracted from pwm_args backlight: lp855x: Explicitly apply PWM config extracted from pwm_args backlight: lp8788: Explicitly apply PWM config extracted from pwm_args backlight: pwm_bl: Use pwm_get_args() where appropriate fbdev: ssd1307fb: Use pwm_get_args() where appropriate regulator: pwm: Use pwm_get_args() where appropriate leds: pwm: Use pwm_get_args() where appropriate input: misc: max77693: Use pwm_get_args() where appropriate ...
2016-05-25drm/amd: add Kconfig dependency for ACP on DRM_AMDGPUJeff Mahoney1-0/+1
The DRM_AMD_ACP option doesn't have any dependencies and selects MFD_CORE, which results in MFD_CORE=y. Since the code is only called from DRM_AMDGPU, it should depend on it. Adding the dependency results in MFD_CORE being selected as a module again if amdgpu is also a module. Signed-off-by: Jeff Mahoney <jeffm@suse.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2016-05-25drm/amdgpu: Fix hdmi deep color support.Mario Kleiner1-5/+5
When porting the hdmi deep color detection code from radeon-kms to amdgpu-kms apparently some kind of copy and paste error happened, attaching an else branch to the wrong if statement. The result is that hdmi deep color mode is always disabled, regardless of gpu and display capabilities and user wishes, as the code mistakenly thinks that the display doesn't provide the required max_tmds_clock limit and falls back to 8 bpc. This patch fixes deep color support, as tested on a R9 380 Tonga Pro + suitable display, and should be backported to all kernels with amdgpu-kms support. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Cc: stable@vger.kernel.org Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2016-05-25drm/amdgpu: fix bug in fence driver finiMonk Liu1-1/+1
Using wrong counter for walking fences. Fixes a crash when unloading the driver. Signed-off-by: Monk Liu <Monk.Liu@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2016-05-25Merge tag 'imx-drm-fixes-2016-05-24' of ↵Dave Airlie3-3/+12
git://git.pengutronix.de/git/pza/linux into drm-next imx-drm probing fix Commit 950b410dd1ab ("gpu: ipu-v3: Fix imx-ipuv3-crtc module autoloading") broke probing of the imx-drm driver in the non-modular case because the unset dev->of_node during probing of imx-ipuv3-crtc would cause the component matching to fail. This patch patch instead matches against an of_node pointer stored in platform data, allowing dev->of_node to be left unset for the platform probed imx-ipuv3-crtc devices. * tag 'imx-drm-fixes-2016-05-24' of git://git.pengutronix.de/git/pza/linux: drm/imx: Match imx-ipuv3-crtc components using device node in platform data
2016-05-23Merge branch 'akpm' (patches from Andrew)Linus Torvalds3-3/+11
Merge yet more updates from Andrew Morton: - Oleg's "wait/ptrace: assume __WALL if the child is traced". It's a kernel-based workaround for existing userspace issues. - A few hotfixes - befs cleanups - nilfs2 updates - sys_wait() changes - kexec updates - kdump - scripts/gdb updates - the last of the MM queue - a few other misc things * emailed patches from Andrew Morton <akpm@linux-foundation.org>: (84 commits) kgdb: depends on VT drm/amdgpu: make amdgpu_mn_get wait for mmap_sem killable drm/radeon: make radeon_mn_get wait for mmap_sem killable drm/i915: make i915_gem_mmap_ioctl wait for mmap_sem killable uprobes: wait for mmap_sem for write killable prctl: make PR_SET_THP_DISABLE wait for mmap_sem killable exec: make exec path waiting for mmap_sem killable aio: make aio_setup_ring killable coredump: make coredump_wait wait for mmap_sem for write killable vdso: make arch_setup_additional_pages wait for mmap_sem for write killable ipc, shm: make shmem attach/detach wait for mmap_sem killable mm, fork: make dup_mmap wait for mmap_sem for write killable mm, proc: make clear_refs killable mm: make vm_brk killable mm, elf: handle vm_brk error mm, aout: handle vm_brk failures mm: make vm_munmap killable mm: make vm_mmap killable mm: make mmap_sem for write waits killable for mm syscalls MAINTAINERS: add co-maintainer for scripts/gdb ...
2016-05-23drm/amdgpu: make amdgpu_mn_get wait for mmap_sem killableMichal Hocko1-1/+4
amdgpu_mn_get which is called during ioct path relies on mmap_sem for write. If the waiting task gets killed by the oom killer it would block oom_reaper from asynchronous address space reclaim and reduce the chances of timely OOM resolving. Wait for the lock in the killable mode and return with EINTR if the task got killed while waiting. [arnd@arndb.de: use ERR_PTR() to return from amdgpu_mn_get] Signed-off-by: Michal Hocko <mhocko@suse.com> Acked-by: Vlastimil Babka <vbabka@suse.cz> Reviewed-by: Christian König <christian.koenig@amd.com> Cc: David Airlie <airlied@linux.ie> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-05-23drm/radeon: make radeon_mn_get wait for mmap_sem killableMichal Hocko1-1/+3
radeon_mn_get which is called during ioct path relies on mmap_sem for write. If the waiting task gets killed by the oom killer it would block oom_reaper from asynchronous address space reclaim and reduce the chances of timely OOM resolving. Wait for the lock in the killable mode and return with EINTR if the task got killed while waiting. Signed-off-by: Michal Hocko <mhocko@suse.com> Acked-by: Vlastimil Babka <vbabka@suse.cz> Reviewed-by: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: David Airlie <airlied@linux.ie> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-05-23drm/i915: make i915_gem_mmap_ioctl wait for mmap_sem killableMichal Hocko1-1/+4
i915_gem_mmap_ioctl relies on mmap_sem for write. If the waiting task gets killed by the oom killer it would block oom_reaper from asynchronous address space reclaim and reduce the chances of timely OOM resolving. Wait for the lock in the killable mode and return with EINTR if the task got killed while waiting. Signed-off-by: Michal Hocko <mhocko@suse.com> Acked-by: Vlastimil Babka <vbabka@suse.cz> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: David Airlie <airlied@linux.ie> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-05-23Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linuxLinus Torvalds758-20730/+101399
Pull drm updates from Dave Airlie: "Here's the main drm pull request for 4.7, it's been a busy one, and I've been a bit more distracted in real life this merge window. Lots more ARM drivers, not sure if it'll ever end. I think I've at least one more coming the next merge window. But changes are all over the place, support for AMD Polaris GPUs is in here, some missing GM108 support for nouveau (found in some Lenovos), a bunch of MST and skylake fixes. I've also noticed a few fixes from Arnd in my inbox, that I'll try and get in asap, but I didn't think they should hold this up. New drivers: - Hisilicon kirin display driver - Mediatek MT8173 display driver - ARC PGU - bitstreamer on Synopsys ARC SDP boards - Allwinner A13 initial RGB output driver - Analogix driver for DisplayPort IP found in exynos and rockchip DRM Core: - UAPI headers fixes and C++ safety - DRM connector reference counting - DisplayID mode parsing for Dell 5K monitors - Removal of struct_mutex from drivers - Connector registration cleanups - MST robustness fixes - MAINTAINERS updates - Lockless GEM object freeing - Generic fbdev deferred IO support panel: - Support for a bunch of new panels i915: - VBT refactoring - PLL computation cleanups - DSI support for BXT - Color manager support - More atomic patches - GEM improvements - GuC fw loading fixes - DP detection fixes - SKL GPU hang fixes - Lots of BXT fixes radeon/amdgpu: - Initial Polaris support - GPUVM/Scheduler/Clock/Power improvements - ASYNC pageflip support - New mesa feature support nouveau: - GM108 support - Power sensor support improvements - GR init + ucode fixes. - Use GPU provided topology information vmwgfx: - Add host messaging support gma500: - Some cleanups and fixes atmel: - Bridge support - Async atomic commit support fsl-dcu: - Timing controller for LCD support - Pixel clock polarity support rcar-du: - Misc fixes exynos: - Pipeline clock support - Exynoss4533 SoC support - HW trigger mode support - export HDMI_PHY clock - DECON5433 fixes - Use generic prime functions - use DMA mapping APIs rockchip: - Lots of little fixes vc4: - Render node support - Gamma ramp support - DPI output support msm: - Mostly cleanups and fixes - Conversion to generic struct fence etnaviv: - Fix for prime buffer handling - Allow hangcheck to be coalesced with other wakeups tegra: - Gamme table size fix" * 'drm-next' of git://people.freedesktop.org/~airlied/linux: (1050 commits) drm/edid: add displayid detailed 1 timings to the modelist. (v1.1) drm/edid: move displayid validation to it's own function. drm/displayid: Iterate over all DisplayID blocks drm/edid: move displayid tiled block parsing into separate function. drm: Nuke ->vblank_disable_allowed drm/vmwgfx: Report vmwgfx version to vmware.log drm/vmwgfx: Add VMWare host messaging capability drm/vmwgfx: Kill some lockdep warnings drm/nouveau/gr/gf100-: fix race condition in fecs/gpccs ucode drm/nouveau/core: recognise GM108 chipsets drm/nouveau/gr/gm107-: fix touching non-existent ppcs in attrib cb setup drm/nouveau/gr/gk104-: share implementation of ppc exception init drm/nouveau/gr/gk104-: move rop_active_fbps init to nonctx drm/nouveau/bios/pll: check BIT table version before trying to parse it drm/nouveau/bios/pll: prevent oops when limits table can't be parsed drm/nouveau/volt/gk104: round up in gk104_volt_set drm/nouveau/fb/gm200: setup mmu debug buffer registers at init() drm/nouveau/fb/gk20a,gm20b: setup mmu debug buffer registers at init() drm/nouveau/fb/gf100-: allocate mmu debug buffers drm/nouveau/fb: allow chipset-specific actions for oneinit() ...
2016-05-23drm/i915: Stop automatically retiring requests after a GPU hangdrm-intel-next-fixes-2016-05-25Chris Wilson2-2/+8
Following a GPU hang, we break out of the request loop in order to unlock the struct_mutex for use by the GPU reset. However, if we retire all the requests at that moment, we cannot identify the guilty request after performing the reset. v2: Not automatically retiring requests forces us to recheck for available ringspace. Fixes: f4457ae71fd6 ("drm/i915: Prevent leaking of -EIO from i915_wait_request()") Testcase: igt/gem_reset_stats/ban-* Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Tested-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463137042-9669-4-git-send-email-chris@chris-wilson.co.uk (cherry picked from commit e075a32f515becef66dc849f5eca47409ccf5473) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-05-23drm/i915: Unify intel_ring_begin()Chris Wilson5-261/+89
Combine the near identical implementations of intel_logical_ring_begin() and intel_ring_begin() - the only difference is that the logical wait has to check for a matching ring (which is assumed by legacy). In the process some debug messages are culled as there were following a WARN if we hit an actual error. v2: Updated commentary Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1461833819-3991-12-git-send-email-chris@chris-wilson.co.uk (cherry picked from commit 987046ad65361a8b038fbf8d76d152237fb7acf1) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-05-23drm/i915: Ignore stale wm register values on resume on ilk-bdw (v2)Ville Syrjälä1-0/+6
When we resume the watermark register may contain some BIOS leftovers, or just the hardware reset values. We should ignore those as the pipes will be off anyway, and so frobbing around with intermediate watermarks doesn't make much sense. In fact I think we should just throw the skip_intermediate_wm flag out, and instead properly sanitize the "active" watermarks to match the current plane and pipe states. The actual wm state readout might also need a bit of work. But for now, let's continue with the skip_intermediate_wm to keep the fix more minimal. Fixes this sort of errors on resume [drm:ilk_validate_pipe_wm] LP0 watermark invalid [drm:intel_crtc_atomic_check] No valid intermediate pipe watermarks are possible [drm:intel_display_resume [i915]] *ERROR* Restoring old state failed with -22 and a boatload of subsequent modeset BAT fails on my ILK. v2: - Rebase; the SKL atomic WM patches that just landed changed the WM structure fields in intel_crtc_state slightly. (Matt) Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: ed4a6a7ca853 ("drm/i915: Add two-stage ILK-style watermark programming (v11)") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463159442-20478-1-git-send-email-matthew.d.roper@intel.com (cherry picked from commit e3d5457c7caabb77b3f1d0b09c4a63362e9b04d2) [Jani: rebase on drm-next while cherry-picking] Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-05-23drm/i915/psr: Try to program link training times correctlyDaniel Vetter1-8/+47
The default of 0 is 500us of link training, but that's not enough for some platforms. Decoding this correctly means we're using 2.5ms of link training on these platforms, which fixes flickering issues associated with enabling PSR. v2: Unbotch the math a bit. v3: Drop debug hunk. v4: Improve commit message. Tested-by: Lyude <cpaul@redhat.com> Cc: Lyude <cpaul@redhat.com> Cc: stable@vger.kernel.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95176 Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Sonika Jindal <sonika.jindal@intel.com> Cc: Durgadoss R <durgadoss.r@intel.com> Cc: "Pandiyan, Dhinakaran" <dhinakaran.pandiyan@intel.com> Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: fritsch@kodi.tv Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463590036-17824-2-git-send-email-daniel.vetter@ffwll.ch (cherry picked from commit 50db139018f9c94376d5f4db94a3bae65fdfac14) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-05-23drm/imx: Match imx-ipuv3-crtc components using device node in platform dataPhilipp Zabel3-3/+12
The component master driver imx-drm-core matches component devices using their of_node. Since commit 950b410dd1ab ("gpu: ipu-v3: Fix imx-ipuv3-crtc module autoloading"), the imx-ipuv3-crtc dev->of_node is not set during probing. Before that, of_node was set and caused an of: modalias to be used instead of the platform: modalias, which broke module autoloading. On the other hand, if dev->of_node is not set yet when the imx-ipuv3-crtc probe function calls component_add, component matching in imx-drm-core fails. While dev->of_node will be set once the next component tries to bring up the component master, imx-drm-core component binding will never succeed if one of the crtc devices is probed last. Add of_node to the component platform data and match against the pdata->of_node instead of dev->of_node in imx-drm-core to work around this problem. Cc: <stable@vger.kernel.org> # 4.4.x Fixes: 950b410dd1ab ("gpu: ipu-v3: Fix imx-ipuv3-crtc module autoloading") Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Fabio Estevam <fabio.estevam@nxp.com> Tested-by: Lothar Waßmann <LW@KARO-electronics.de> Tested-by: Heiko Schocher <hs@denx.de> Tested-by: Chris Ruehl <chris.ruehl@gtsys.com.hk>
2016-05-23drm/i915/bxt: Adjusting the error in horizontal timings retrievalRamalingam C1-9/+88
In BXT DSI there is no regs programmed with few horizontal timings in Pixels but txbyteclkhs.. So retrieval process adds some ROUND_UP ERRORS in the process of PIXELS<==>txbyteclkhs. Actually here for the given adjusted_mode, we are calculating the value programmed to the port and then back to the horizontal timing param in pixels. This is the expected value at the end of get_config, including roundup errors. And if that is same as retrieved value from port, then retrieved (HW state) adjusted_mode's horizontal timings are corrected to match with SW state to nullify the errors. Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1461053894-5058-2-git-send-email-ramalingam.c@intel.com (cherry picked from commit 042ab0c3c40be1efcaad6b526173b5536fc6c3bf) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-05-23drm/i915: Don't leave old junk in ilk active watermarks on readoutVille Syrjälä1-0/+2
When we read out the watermark state from the hardware we're supposed to transfer that into the active watermarks, but currently we fail to any part of the active watermarks that isn't explicitly written. Let's clear it all upfront. Looks like this has been like this since the beginning, when I added the readout. No idea why I didn't clear it up. Cc: Matt Roper <matthew.d.roper@intel.com> Fixes: 243e6a44b9ca ("drm/i915: Init HSW watermark tracking in intel_modeset_setup_hw_state()") Cc: stable@vger.kernel.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463151318-14719-2-git-send-email-ville.syrjala@linux.intel.com (cherry picked from commit 15606534bf0a65d8a74a90fd57b8712d147dbca6) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-05-23drm/i915: s/DPPL/DPLL/ for SKL DPLLsVille Syrjälä1-3/+3
SKL DPLLs shouldn't be called DPPLs. Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Fixes: 2edd6443e3d0 ("drm/i915: Use a table to initilize shared dplls") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1462993473-8254-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> (cherry picked from commit d5aab9d40135725cbe81ed5e3af5209382063193) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-05-23drm/i915: Fix gen8 semaphores id for legacy modeChris Wilson2-3/+9
With the introduction of a distinct engine->id vs the hardware id, we need to fix up the value we use for selecting the target engine when signaling a semaphore. Note that these values can be merged with engine->guc_id. Fixes: de1add360522c876c25ef2bbbbab1c94bdb509ab Cc: stable@vger.kernel.org # v4.6 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1461932305-14637-3-git-send-email-chris@chris-wilson.co.uk (cherry picked from commit 215a7e3210eb208abe634480741e418b5a8bf60c) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-05-23drm/i915: Set crtc_state->lane_count for HDMIAnder Conselvan de Oliveira2-1/+7
Set the lane count for HDMI to 4. This will make it easier to unduplicate CHV phy code. This also fixes the the soft reset programming for HDMI with CHV. After commit a8f327fb8464 ("drm/i915: Clean up CHV lane soft reset programming"), it wouldn't set the right bits for PCS23 since it relied on a lane count that was never set. v2: Set lane_count in *_get_config() to please state checker. (0day) v3: Set lane_count for DDI in DVI mode too. (CI) v4: Add note about CHV soft lane reset. (Ander) Fixes: a8f327fb8464 ("drm/i915: Clean up CHV lane soft reset programming") Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Jim Bride <jim.bride@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1461761065-21195-2-git-send-email-ander.conselvan.de.oliveira@intel.com (cherry picked from commit d4d6279abe9a4a2d52115bad122118db4995df17) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-05-23drm/i915/BXT: Retrieving the horizontal timing for DSIRamalingam C1-7/+37
Retriving the horizontal timings from the port registers as part of get_config(). This fixes a division by zero: [ 56.916557] divide error: 0000 [#1] PREEMPT SMP [ 56.921741] Modules linked in: i915(+) drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm intel_gtt agpgart cf g80211 rfkill binfmt_misc ax88179_178a kvm_intel kvm irqbypass crc32c_intel efivars tpm_tis tpm fuse [ 56.944106] CPU: 3 PID: 1097 Comm: modprobe Not tainted 4.6.0-rc4+ #433 [ 56.951501] Hardware name: Intel Corp. Broxton M/RVP, BIOS BXT1RVPA.X64.0131.B30.1604142217 04/14/2016 [ 56.961908] task: ffff88007a854d00 ti: ffff88007aea0000 task.ti: ffff88007aea0000 [ 56.970273] RIP: 0010:[<ffffffffa01235b2>] [<ffffffffa01235b2>] drm_mode_hsync+0x22/0x40 [drm] [ 56.980043] RSP: 0018:ffff88007aea3788 EFLAGS: 00010206 [ 56.985982] RAX: 000000000788b600 RBX: ffff880073c22108 RCX: 0000000000000000 [ 56.993957] RDX: 0000000000000000 RSI: ffff88007ab06800 RDI: ffff880073c22108 [ 57.001935] RBP: ffff88007aea3788 R08: 0000000000000001 R09: ffff880073c221e8 [ 57.009903] R10: ffff880073c22108 R11: 0000000000000001 R12: ffff88007a300000 [ 57.017872] R13: ffff880073c22000 R14: ffff880175f78000 R15: ffff880175f78798 [ 57.025849] FS: 00007f105d3e6700(0000) GS:ffff88017fd80000(0000) knlGS:0000000000000000 [ 57.034894] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 57.041317] CR2: 00007f4d485101d0 CR3: 000000007a820000 CR4: 00000000003406e0 [ 57.049292] Stack: [ 57.051539] ffff88007aea37a0 ffffffffa043b632 ffff880175f787c8 ffff88007aea3810 [ 57.059825] ffffffffa043d59e ffff880175f787b0 ffff88007ab68c00 ffff88007aea37f0 [ 57.068128] ffff880073c221e8 ffff880073c22108 ffff880175f78780 ffff880100000000 [ 57.076430] Call Trace: [ 57.079254] [<ffffffffa043b632>] intel_mode_from_pipe_config+0x82/0xb0 [i915] [ 57.087405] [<ffffffffa043d59e>] intel_modeset_setup_hw_state+0x55e/0xd60 [i915] [ 57.095847] [<ffffffffa043ff94>] intel_modeset_init+0x8e4/0x1630 [i915] [ 57.103415] [<ffffffffa047bcf0>] i915_driver_load+0xbe0/0x1980 [i915] [ 57.110745] [<ffffffffa0116c19>] drm_dev_register+0xa9/0xc0 [drm] [ 57.117681] [<ffffffffa011921d>] drm_get_pci_dev+0x8d/0x1e0 [drm] [ 57.124600] [<ffffffff8195f942>] ? _raw_spin_unlock_irqrestore+0x42/0x70 [ 57.132253] [<ffffffffa03b0384>] i915_pci_probe+0x34/0x50 [i915] [ 57.139070] [<ffffffff8149c375>] local_pci_probe+0x45/0xa0 [ 57.145303] [<ffffffff8149d300>] ? pci_match_device+0xe0/0x110 [ 57.151924] [<ffffffff8149d6cb>] pci_device_probe+0xdb/0x130 [ 57.158355] [<ffffffff81579b93>] driver_probe_device+0x223/0x440 [ 57.165169] [<ffffffff81579e85>] __driver_attach+0xd5/0x100 [ 57.171500] [<ffffffff81579db0>] ? driver_probe_device+0x440/0x440 [ 57.178510] [<ffffffff81577736>] bus_for_each_dev+0x66/0xa0 [ 57.184841] [<ffffffff815793de>] driver_attach+0x1e/0x20 [ 57.190881] [<ffffffff81578d6e>] bus_add_driver+0x1ee/0x280 [ 57.197212] [<ffffffff8157abc0>] driver_register+0x60/0xe0 [ 57.203447] [<ffffffff8149bc50>] __pci_register_driver+0x60/0x70 [ 57.210285] [<ffffffffa0119450>] drm_pci_init+0xe0/0x110 [drm] [ 57.216911] [<ffffffff810dcd8d>] ? trace_hardirqs_on+0xd/0x10 [ 57.223434] [<ffffffffa023a000>] ? 0xffffffffa023a000 [ 57.229237] [<ffffffffa023a092>] i915_init+0x92/0x99 [i915] [ 57.235570] [<ffffffff810003db>] do_one_initcall+0xab/0x1d0 [ 57.241900] [<ffffffff810f9eef>] ? rcu_read_lock_sched_held+0x7f/0x90 [ 57.249205] [<ffffffff81204f18>] ? kmem_cache_alloc_trace+0x248/0x2b0 [ 57.256509] [<ffffffff811a5eee>] ? do_init_module+0x27/0x1d9 [ 57.262934] [<ffffffff811a5f26>] do_init_module+0x5f/0x1d9 [ 57.269167] [<ffffffff8112392f>] load_module+0x20ef/0x27b0 [ 57.275401] [<ffffffff8111f8e0>] ? store_uevent+0x40/0x40 [ 57.281541] [<ffffffff81124243>] SYSC_finit_module+0xc3/0xf0 [ 57.287969] [<ffffffff8112428e>] SyS_finit_module+0xe/0x10 [ 57.294203] [<ffffffff81960069>] entry_SYSCALL_64_fastpath+0x1c/0xac [ 57.301406] Code: ff 5d c3 66 0f 1f 44 00 00 0f 1f 44 00 00 8b 87 d8 00 00 00 55 48 89 e5 85 c0 75 22 8b 4f 68 85 c9 78 1b 69 47 58 e8 03 00 00 99 <f7> f9 b9 d3 4d 62 10 05 f4 01 00 00 f7 e1 89 d0 c1 e8 06 5d c3 [ 57.322964] RIP [<ffffffffa01235b2>] drm_mode_hsync+0x22/0x40 [drm] [ 57.330103] RSP <ffff88007aea3788> [ 57.334276] ---[ end trace d414224cb2e2a4cf ]--- [ 57.339861] modprobe (1097) used greatest stack depth: 12048 bytes left Fixes: 6f0e7535e7e1 ("drm/i915/BXT: Get pipe conf from the port registers") Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Acked-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1461053894-5058-1-git-send-email-ramalingam.c@intel.com (cherry picked from commit cefc4e18785123326c5d4d985085e32160fef7f5) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-05-23drm/i915: Protect gen7 irq_seqno_barrier with uncore lockChris Wilson1-1/+7
Faced with sporadic machine hangs on gen7, that mimic the issue of concurrent writes to the same cacheline and seem to start with commit 9b9ed3093613 (drm/i915: Remove forcewake dance from seqno/irq barrier on legacy gen6+), let us restore the spinlock around the mmio read. Fixes: 9b9ed3093613 (drm/i915: Remove forcewake dance from seqno/irq...) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1461744121-27051-1-git-send-email-chris@chris-wilson.co.uk Tested-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> (cherry picked from commit bcbdb6d01150dcc1769ddc9baaaf7f102f27f919) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-05-23drm/i915: Re-enable GGTT earlier during resume on pre-gen6 platformsVille Syrjälä5-3/+20
Move the intel_enable_gtt() call to happen before we touch the GTT during resume. Right now it's done way too late. Before commit ebb7c78d358b ("agp/intel-gtt: Only register fake agp driver for gen1") it was actually done earlier on account of also getting called from the resume hook of the fake agp driver. With the fake agp driver no longer getting registered we must move the call up. The symptoms I've seen on my 830 machine include lowmem corruption, other kinds of memory corruption, and straight up hung machine during or just after resume. Not really sure what causes the memory corruption, but so far I've not seen any with this fix. I think we shouldn't really need to call this during init, but we have been doing that so I've decided to keep the call. However moving that call earlier could be prudent as well. Doing it right after the intel-gtt probe seems appropriate. Also tested this on 946gz,elk,ilk and all seemed quite happy with this change. v2: Reorder init_hw vs. enable_hw functions (Chris) Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: drm-intel-fixes@lists.freedesktop.org Fixes: ebb7c78d358b ("agp/intel-gtt: Only register fake agp driver for gen1") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1462559755-353-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (cherry picked from commit ac840ae53573d9f435c88c131f6707a79aecb466) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-05-23drm/i915: Determine DP++ type 1 DVI adaptor presence based on VBTVille Syrjälä4-4/+75
DP dual mode type 1 DVI adaptors aren't required to implement any registers, so it's a bit hard to detect them. The best way would be to check the state of the CONFIG1 pin, but we have no way to do that. So as a last resort, check the VBT to see if the HDMI port is in fact a dual mode capable DP port. v2: Deal with VBT code reorganization Deal with DRM_DP_DUAL_MODE_UNKNOWN Reduce DEVICE_TYPE_DP_DUAL_MODE_BITS a bit Accept both DP and HDMI dvo_port in VBT as my BSW at least declare its DP port as HDMI :( v3: Ignore DEVICE_TYPE_NOT_HDMI_OUTPUT (Shashank) Cc: stable@vger.kernel.org Cc: Tore Anderson <tore@fud.no> Reported-by: Tore Anderson <tore@fud.no> Fixes: 7a0baa623446 ("Revert "drm/i915: Disable 12bpc hdmi for now"") Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1462362322-31278-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> (cherry picked from commit d61992565bd3cc5b66d74ed2e96df043c2a207e2) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-05-23drm/i915: Enable/disable TMDS output buffers in DP++ adaptor as neededVille Syrjälä3-0/+33
To save a bit of power, let's try to turn off the TMDS output buffers in DP++ adaptors when we're not driving the port. v2: Let's not forget DDI, toss in a debug message while at it v3: Just do the TMDS output control based on adaptor type. With the helper getting passed the type, we wouldn't actually have to check at all in the driver, but the check eliminates the debug output more honest Cc: stable@vger.kernel.org Cc: Tore Anderson <tore@fud.no> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1462216105-20881-4-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> (cherry picked from commit b2ccb822d376d1bbbe5d1f9118d1488b25e6bc6d) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-05-23drm/i915: Respect DP++ adaptor TMDS clock limitVille Syrjälä2-8/+55
Try to detect the max TMDS clock limit for the DP++ adaptor (if any) and take it into account when checking the port clock. Note that as with the sink (HDMI vs. DVI) TMDS clock limit we'll ignore the adaptor TMDS clock limit in the modeset path, in case users are already "overclocking" their TMDS links. One subtle change here is that we'll have to respect the adaptor TMDS clock limit when we decide whether to do 12bpc or 8bpc, otherwise we might end up picking 12bpc and accidentally driving the TMDS link out of spec even when the user chose a mode that fits wihting the limits at 8bpc. This means you can't "overclock" your DP++ dongle at 12bpc anymore, but you can continue to do so at 8bpc. Note that for simplicity we'll use the I2C access method for all dual mode adaptors including type 2. Otherwise we'd have to start mixing DP AUX and HDMI together. In the future we may need to do that if we come across any board designs that don't hook up the DDC pins to the DP++ connectors. Such boards would obviously only work with type 2 dual mode adaptors, and not type 1. v2: Store adaptor type under indel_hdmi->dp_dual_mode Deal with DRM_DP_DUAL_MODE_UNKNOWN Pass adaptor type to drm_dp_dual_mode_max_tmds_clock(), and use it for type1 adaptors as well Cc: stable@vger.kernel.org Reported-by: Tore Anderson <tore@fud.no> Fixes: 7a0baa623446 ("Revert "drm/i915: Disable 12bpc hdmi for now"") Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1462216105-20881-3-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> (cherry picked from commit b1ba124d8e95cca48d33502a4a76b1ed09d213ce) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-05-23drm: Add helper for DP++ adaptorsVille Syrjälä2-1/+367
Add a helper which aids in the identification of DP dual mode (aka. DP++) adaptors. There are several types of adaptors specified: type 1 DVI, type 1 HDMI, type 2 DVI, type 2 HDMI Type 1 adaptors have a max TMDS clock limit of 165MHz, type 2 adaptors may go as high as 300MHz and they provide a register informing the source device what the actual limit is. Supposedly also type 1 adaptors may optionally implement this register. This TMDS clock limit is the main reason why we need to identify these adaptors. Type 1 adaptors provide access to their internal registers and the sink DDC bus through I2C. Type 2 adaptors provide this access both via I2C and I2C-over-AUX. A type 2 source device may choose to implement either of these methods. If a source device implements the I2C-over-AUX method, then the driver will obviously need specific support for such adaptors since the port is driven like an HDMI port, but DDC communication happes over the AUX channel. This helper should be enough to identify the adaptor type (some type 1 DVI adaptors may be a slight exception) and the maximum TMDS clock limit. Another feature that may be available is control over the TMDS output buffers on the adaptor, possibly allowing for some power saving when the TMDS link is down. Other user controllable features that may be available in the adaptors are downstream i2c bus speed control when using i2c-over-aux, and some control over the CEC pin. I chose not to provide any helper functions for those since I have no use for them in i915 at this time. The rest of the registers in the adaptor are mostly just information, eg. IEEE OUI, hardware and firmware revision, etc. v2: Pass adaptor type to helper functions to ease driver implementation Fix a bunch of typoes (Paulo) Add DRM_DP_DUAL_MODE_UNKNOWN for the case where we don't (yet) know the type (Paulo) Reject 0x00 and 0xff DP_DUAL_MODE_MAX_TMDS_CLOCK values (Paulo) Adjust drm_dp_dual_mode_detect() type2 vs. type1 detection to ease future LSPCON enabling Remove the unused DP_DUAL_MODE_LAST_RESERVED define v3: Fix kernel doc function argument descriptions (Jani) s/NONE/UNKNOWN/ in drm_dp_dual_mode_detect() docs Add kernel doc for enum drm_dp_dual_mode_type Actually build the docs Fix more typoes v4: Adjust code indentation of type2 adaptor detection (Shashank) Add debug messages for failurs cases (Shashank) v5: EXPORT_SYMBOL(drm_dp_dual_mode_read) (Paulo) Cc: stable@vger.kernel.org Cc: Tore Anderson <tore@fud.no> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> (v4) Link: http://patchwork.freedesktop.org/patch/msgid/1462542412-25533-1-git-send-email-ville.syrjala@linux.intel.com (cherry picked from commit ede53344dbfd1dd43bfd73eb6af743d37c56a7c3) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-05-23drm/edid: add displayid detailed 1 timings to the modelist. (v1.1)Dave Airlie1-0/+108
The tiled 5K Dell monitor appears to be hiding it's tiled mode inside the displayid timings block, this patch parses this blocks and adds the modes to the modelist. v1.1: add missing __packed. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95207 Signed-off-by: Dave Airlie <airlied@redhat.com>
2016-05-23drm/edid: move displayid validation to it's own function.Dave Airlie1-18/+26
We need to use this for validating modeline additions. Signed-off-by: Dave Airlie <airlied@redhat.com>
2016-05-23drm/displayid: Iterate over all DisplayID blocksTomas Bzatek1-13/+19
This will iterate over all DisplayID blocks found in the buffer. Previously only the first block was parsed. https://bugs.freedesktop.org/show_bug.cgi?id=95207 Signed-off-by: Tomas Bzatek <tomas@bzatek.net> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2016-05-23drm/edid: move displayid tiled block parsing into separate function.Dave Airlie1-51/+59
This just makes the code easier to follow. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2016-05-22x86: remove pointless uaccess_32.h complexityLinus Torvalds1-3/+1
I'm looking at trying to possibly merge the 32-bit and 64-bit versions of the x86 uaccess.h implementation, but first this needs to be cleaned up. For example, the 32-bit version of "__copy_to_user_inatomic()" is mostly the special cases for the constant size, and it's actually never relevant. Every user except for one aren't actually using a constant size anyway, and the one user that uses it is better off just using __put_user() instead. So get rid of the unnecessary complexity. [ The same cleanup should likely happen to __copy_from_user_inatomic() as well, but that one has a lot more users that I need to take a look at first ] Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-05-20Merge tag 'staging-4.7-rc1' of ↵Linus Torvalds5-35/+20
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging Pull staging and IIO driver updates from Greg KH: "Here's the big staging and iio driver update for 4.7-rc1. I think we almost broke even with this release, only adding a few more lines than we removed, which isn't bad overall given that there's a bunch of new iio drivers added. The Lustre developers seem to have woken up from their sleep and have been doing a great job in cleaning up the code and pruning unused or old cruft, the filesystem is almost readable :) Other than that, just a lot of basic coding style cleanups in the churn. All have been in linux-next for a while with no reported issues" * tag 'staging-4.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (938 commits) Staging: emxx_udc: emxx_udc: fixed coding style issue staging/gdm724x: fix "alignment should match open parenthesis" issues staging/gdm724x: Fix avoid CamelCase staging: unisys: rename misleading var ii with frag staging: unisys: visorhba: switch success handling to error handling staging: unisys: visorhba: main path needs to flow down the left margin staging: unisys: visorinput: handle_locking_key() simplifications staging: unisys: visorhba: fail gracefully for thread creation failures staging: unisys: visornic: comment restructuring and removing bad diction staging: unisys: fix format string %Lx to %llx for u64 staging: unisys: remove unused struct members staging: unisys: visorchannel: correct variable misspelling staging: unisys: visorhba: replace functionlike macro with function staging: dgnc: Need to check for NULL of ch staging: dgnc: remove redundant condition check staging: dgnc: fix 'line over 80 characters' staging: dgnc: clean up the dgnc_get_modem_info() staging: lustre: lnet: enable configuration per NI interface staging: lustre: o2iblnd: properly set ibr_why staging: lustre: o2iblnd: remove last of kiblnd_tunables_fini ...
2016-05-20Merge tag 'devicetree-for-4.7' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux Pull devicetree updates from Rob Herring: - Rewrite of the unflattening code to avoid recursion and lessen the stack usage. - Rewrite of the phandle args parsing code to get rid of the fixed args size. This is needed for IOMMU code. - Sync to latest dtc which adds more dts style checking. These warnings are enabled with "W=1" compiles. - Tegra documentation updates related to the above warnings. - A bunch of spelling and other doc fixes. - Various vendor prefix additions. * tag 'devicetree-for-4.7' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux: (52 commits) devicetree: Add Creative Technology vendor id gpio: dt-bindings: add ibm,ppc4xx-gpio binding of/unittest: Remove unnecessary module.h header inclusion drivers/of: Fix build warning in populate_node() drivers/of: Fix depth when unflattening devicetree of: dynamic: changeset prop-update revert fix drivers/of: Export of_detach_node() drivers/of: Return allocated memory from of_fdt_unflatten_tree() drivers/of: Specify parent node in of_fdt_unflatten_tree() drivers/of: Rename unflatten_dt_node() drivers/of: Avoid recursively calling unflatten_dt_node() drivers/of: Split unflatten_dt_node() of: include errno.h in of_graph.h of: document refcount incrementation of of_get_cpu_node() Documentation: dt: soc: fix spelling mistakes Documentation: dt: power: fix spelling mistake Documentation: dt: pinctrl: fix spelling mistake Documentation: dt: opp: fix spelling mistake Documentation: dt: net: fix spelling mistakes Documentation: dt: mtd: fix spelling mistake ...
2016-05-21drm: Nuke ->vblank_disable_allowedDaniel Vetter13-39/+0
This was added in commit 0a3e67a4caac273a3bfc4ced3da364830b1ab241 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Tue Sep 30 12:14:26 2008 -0700 drm: Rework vblank-wait handling to allow interrupt reduction. to stay backwards-compatible with old UMS code that didn't even tell the kernel when it did a modeset, so that the kernel could save/restore vblank counters. At worst this means vblanks will be somewhat funky on a setup that very likely no one still runs. So let's just nuke it. Plan B would be to set it unconditionally in drm_vblank_init for kms drivers, instead of in each driver separately. So if this patch breaks anything please only restore the hunks in drmP.h and drm_irq.c, plus add a check for DRIVER_MODESET in drm_vblank_init. Stumbled over this in a discussion on irc with Chris. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Russell King <rmk+kernel@arm.linux.org.uk> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Eric Anholt <eric@anholt.net> Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Cc: Inki Dae <inki.dae@samsung.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Mark Yao <mark.yao@rock-chips.com> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Liviu Dudau <Liviu.Dudau@arm.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2016-05-21Merge tag 'vmwgfx-next-160520' of ↵Dave Airlie8-16/+653
git://people.freedesktop.org/~thomash/linux into drm-next Pull request of 2016-05-20 * tag 'vmwgfx-next-160520' of git://people.freedesktop.org/~thomash/linux: drm/vmwgfx: Report vmwgfx version to vmware.log drm/vmwgfx: Add VMWare host messaging capability drm/vmwgfx: Kill some lockdep warnings
2016-05-21Merge branch 'linux-4.7' of git://github.com/skeggsb/linux into drm-nextDave Airlie203-843/+1853
Nothing too exciting here, there's a larger chunk of work that still needs more testing but not likely to get that done today - so - here's the rest of it. Assuming nothing else goes horribly wrong, I should be able to send the rest Monday if it isn't too late.... Changes: - Improvements to power sensor support - Initial attempt at GM108 support - Minor fixes to GR init + ucode - Make use of topology information (provided by the GPU) in various places, should at least fix some fault recovery issues and engine/runlist mapping confusion on newer GPUs. * 'linux-4.7' of git://github.com/skeggsb/linux: (51 commits) drm/nouveau/gr/gf100-: fix race condition in fecs/gpccs ucode drm/nouveau/core: recognise GM108 chipsets drm/nouveau/gr/gm107-: fix touching non-existent ppcs in attrib cb setup drm/nouveau/gr/gk104-: share implementation of ppc exception init drm/nouveau/gr/gk104-: move rop_active_fbps init to nonctx drm/nouveau/bios/pll: check BIT table version before trying to parse it drm/nouveau/bios/pll: prevent oops when limits table can't be parsed drm/nouveau/volt/gk104: round up in gk104_volt_set drm/nouveau/fb/gm200: setup mmu debug buffer registers at init() drm/nouveau/fb/gk20a,gm20b: setup mmu debug buffer registers at init() drm/nouveau/fb/gf100-: allocate mmu debug buffers drm/nouveau/fb: allow chipset-specific actions for oneinit() drm/nouveau/gr/gm200-: fix bad hardcoding of a max-tpcs-per-gpc value drm/nouveau/gr/gm200-: rop count == ltc count drm/nouveau/gr/gm200: modify the mask when copying mmu settings from fb drm/nouveau/gr/gm200: move some code into init_gpc_mmu() hook drm/nouveau/gr/gm200: make generate_main() static drm/nouveau/gr/gf100-: abstract fetching rop count drm/nouveau/gr/gf100-: rename magic_not_rop_nr to screen_tile_row_offset drm/nouveau/gr/gf100-: remove hardcoded idle_timeout values ...
2016-05-20drm/vmwgfx: Report vmwgfx version to vmware.logSinclair Yeh3-2/+25
When tracking down a customer issue, it is useful to know exactly which version of the vmwgfx they are using. Since vmware.log is often the only available debug log, report vmwgfx version in there. Signed-off-by: Sinclair Yeh <syeh@vmware.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
2016-05-20drm/vmwgfx: Add VMWare host messaging capabilitySinclair Yeh2-0/+607
This patch adds capabilities for a VMWare guest to send and receive messages from the host, and adds functions to sending log messages to vmware.log and to request device settings that aren't available through the virtual hardware, e.g. certain settings in the VMX file. Signed-off-by: Sinclair Yeh <syeh@vmware.com> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
2016-05-20drm/vmwgfx: Kill some lockdep warningsThomas Hellstrom5-14/+21
Some global KMS state that is elsewhere protected by the mode_config mutex here needs to be protected with a local mutex. Remove corresponding lockdep checks and introduce a new driver-private global_kms_state_mutex, and make sure its locking order is *after* the crtc locks in order to avoid having to release those when the new mutex is taken. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Brian Paul <brianp@vmware.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com> Cc: <stable@vger.kernel.org> # 4.6
2016-05-20drm/nouveau/gr/gf100-: fix race condition in fecs/gpccs ucodeBen Skeggs14-71/+85
This is a simplied version of the fix by Roy in fdo#93629. While this doesn't appear to fix the issues for the users in that report, it's a real issue that deserves to be resolved. Reported-by: Roy Spliet <rspliet@eclipso.eu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-05-20drm/nouveau/core: recognise GM108 chipsetsBen Skeggs1-0/+35
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-05-20drm/nouveau/gr/gm107-: fix touching non-existent ppcs in attrib cb setupBen Skeggs1-1/+3
Also removes an XXX; according to nvgpu headers the field is called NV_PGRAPH_GPCS_SWDX_TC_BETA_CB_SIZE_DIV3, so, apparently not some magic we need to figure out :) Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-05-20drm/nouveau/gr/gk104-: share implementation of ppc exception initBen Skeggs7-7/+31
This was really inconsistent, some implementations could touch PPCs that didn't exist, others neglected to touch ones that did. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-05-20drm/nouveau/gr/gk104-: move rop_active_fbps init to nonctxBen Skeggs15-28/+36
Matches newer RM. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-05-20drm/nouveau/bios/pll: check BIT table version before trying to parse itBen Skeggs1-4/+6
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>