- 04 7月, 2016 3 次提交
-
-
由 Thierry Reding 提交于
In order to use the HDA codec to forward audio data to the HDMI codec it needs the ELD that is parsed from the monitor's EDID. Also implement an interoperability mechanism between the HDA controller and the HDMI codec. This uses vendor-defined scratch registers to pass data from the HDMI codec driver to the HDMI driver (that implements the receiving end of the HDMI codec). A custom format is used to pass audio sample rate and channel count to the HDMI driver. Signed-off-by: NThierry Reding <treding@nvidia.com>
-
由 Thierry Reding 提交于
Current generations of Tegra do not support deep color modes, so force 8 bits per color even if the connected monitor or panel supports more. Signed-off-by: NThierry Reding <treding@nvidia.com>
-
由 Thierry Reding 提交于
The code to set a video mode is common to all types of outputs that the SOR can drive. Extract it into a separate function so that it can be shared. Signed-off-by: NThierry Reding <treding@nvidia.com>
-
- 01 7月, 2016 4 次提交
-
-
由 Thierry Reding 提交于
This function is useful in both eDP and DP modes, so split it out in anticipation of adding DP support. Signed-off-by: NThierry Reding <treding@nvidia.com>
-
由 Thierry Reding 提交于
Use a slightly more sensible name, tegra_sor_compute_config(). Signed-off-by: NThierry Reding <treding@nvidia.com>
-
由 Thierry Reding 提交于
Switching the SOR parent clock can glitch if done while the clock is enabled. Extract a common function that can be used to disable the module clock, switch the parent and reenable the module clock. Signed-off-by: NThierry Reding <treding@nvidia.com>
-
由 Jon Hunter 提交于
The DPAUX pins are shared with an internal I2C controller. To allow these pins to be muxed to the I2C controller, register a pinctrl device for the DPAUX device. This is based upon work by Thierry Reding <treding@nvidia.com>. Signed-off-by: NJon Hunter <jonathanh@nvidia.com> Signed-off-by: NThierry Reding <treding@nvidia.com>
-
- 30 6月, 2016 3 次提交
-
-
由 Jon Hunter 提交于
To utilise the DPAUX on Tegra, the SOR power partition must be enabled. Now that Tegra supports the generic PM domain framework we manage the SOR power partition via this framework for DPAUX. However, the sequence for gating/ungating the SOR power partition requires that the DPAUX reset is asserted/de-asserted at the time the SOR power partition is gated/ungated, respectively. Now that the reset control core assumes that resets are exclusive, the Tegra generic PM domain code and the DPAUX driver cannot request the same reset unless we mark the resets as shared. Sharing resets will not work in this case because we cannot guarantee that the reset will be asserted/de-asserted at the appropriate time. Therefore, given that the Tegra generic PM domain code will handle the DPAUX reset, do not request the reset in the DPAUX driver if the DPAUX device has a PM domain associated. Signed-off-by: NJon Hunter <jonathanh@nvidia.com> Signed-off-by: NThierry Reding <treding@nvidia.com>
-
由 Jon Hunter 提交于
In preparation for adding pinctrl support for the DPAUX pads, add a couple of helpers functions to configure the pads and control their power. Please note that although a simple if-statement could be used instead of a case statement for configuring the pads as there are only two possible modes, a case statement is used because when integrating with the pinctrl framework, we need to be able to handle invalid modes that could be passed. Signed-off-by: NJon Hunter <jonathanh@nvidia.com> Signed-off-by: NThierry Reding <treding@nvidia.com>
-
由 Jon Hunter 提交于
If the probing of the DPAUX fails, then clocks are left enabled and the DPAUX reset de-asserted. Add code to perform the necessary clean-up on probe failure by disabling clocks and asserting the reset. Signed-off-by: NJon Hunter <jonathanh@nvidia.com> Signed-off-by: NThierry Reding <treding@nvidia.com>
-
- 23 6月, 2016 11 次提交
-
-
由 Thierry Reding 提交于
The local 'val' variable is used to store a value and immediately return it to its caller, and hence serves no purpose. Just drop it and directly return the value. Signed-off-by: NThierry Reding <treding@nvidia.com>
-
由 Thierry Reding 提交于
This array never needs to be modified and therefore can be read-only data. Signed-off-by: NThierry Reding <treding@nvidia.com>
-
由 Thierry Reding 提交于
There's no need to wrap the BIT() macro into an extra set of parentheses because it's already implemented to use its own set. Signed-off-by: NThierry Reding <treding@nvidia.com>
-
由 Thierry Reding 提交于
Insert a number of blank lines in places where they increase readability of the code. Also collapse various variable declarations to shorten some functions and finally rewrite some code for readability. Signed-off-by: NThierry Reding <treding@nvidia.com>
-
由 Thierry Reding 提交于
Fix a couple of occurrences where no blank line was used to separate variable declarations from code or where block comments were wrongly formatted. Signed-off-by: NThierry Reding <treding@nvidia.com>
-
由 Thierry Reding 提交于
Use kcalloc() to allocate arrays rather than passing the product of the size per element by the number of elements to kzalloc(). Signed-off-by: NThierry Reding <treding@nvidia.com>
-
由 Thierry Reding 提交于
The local 'pos' variable doesn't serve any purpose other than being a shortcut for pb->pos, but the result doesn't remove much, so simply drop the local variable. Signed-off-by: NThierry Reding <treding@nvidia.com>
-
由 Thierry Reding 提交于
find_first_zero_bit() returns an unsigned long, so make the local variable that stores the result the same type for consistency. Signed-off-by: NThierry Reding <treding@nvidia.com>
-
由 Thierry Reding 提交于
IDs can never be negative so use unsigned int. In some instances an explicitly sized type (such as u32) was used for no particular reason, so turn those into unsigned int as well for consistency. Signed-off-by: NThierry Reding <treding@nvidia.com>
-
由 Thierry Reding 提交于
The number of channels, syncpoints, bases and mlocks can never be negative, so use unsigned int instead of int. Also make loop variables the same type for consistency. Signed-off-by: NThierry Reding <treding@nvidia.com>
-
由 Bhaktipriya Shridhar 提交于
System workqueues have been able to handle high level of concurrency for a long time now and there's no reason to use dedicated workqueues just to gain concurrency. Since the workqueue host->intr_wq is involved in sync point interrupts, and sync point wait and is not being used on a memory reclaim path, dedicated host->intr_wq has been replaced with the use of system_wq. Unlike a dedicated per-cpu workqueue created with create_workqueue(), system_wq allows multiple work items to overlap executions even on the same CPU; however, a per-cpu workqueue doesn't have any CPU locality or global ordering guarantees unless the target CPU is explicitly specified and thus the increase of local concurrency shouldn't make any difference. cancel_work_sync() has been used in _host1x_free_syncpt_irq() to ensure that no work is pending by the time exit path runs. Signed-off-by: NBhaktipriya Shridhar <bhaktipriya96@gmail.com> Acked-by: NTejun Heo <tj@kernel.org> Signed-off-by: NThierry Reding <treding@nvidia.com>
-
- 28 5月, 2016 1 次提交
-
-
由 Arnd Bergmann 提交于
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: NArnd 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: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 25 5月, 2016 3 次提交
-
-
由 Jeff Mahoney 提交于
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: NJeff Mahoney <jeffm@suse.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Mario Kleiner 提交于
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: NMario Kleiner <mario.kleiner.de@gmail.com> Cc: stable@vger.kernel.org Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Monk Liu 提交于
Using wrong counter for walking fences. Fixes a crash when unloading the driver. Signed-off-by: NMonk Liu <Monk.Liu@amd.com> Reviewed-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 24 5月, 2016 3 次提交
-
-
由 Michal Hocko 提交于
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: NMichal Hocko <mhocko@suse.com> Acked-by: NVlastimil Babka <vbabka@suse.cz> Reviewed-by: NChristian König <christian.koenig@amd.com> Cc: David Airlie <airlied@linux.ie> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Michal Hocko 提交于
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: NMichal Hocko <mhocko@suse.com> Acked-by: NVlastimil Babka <vbabka@suse.cz> Reviewed-by: NChristian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: David Airlie <airlied@linux.ie> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Michal Hocko 提交于
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: NMichal Hocko <mhocko@suse.com> Acked-by: NVlastimil Babka <vbabka@suse.cz> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: David Airlie <airlied@linux.ie> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 23 5月, 2016 12 次提交
-
-
由 Chris Wilson 提交于
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: f4457ae7 ("drm/i915: Prevent leaking of -EIO from i915_wait_request()") Testcase: igt/gem_reset_stats/ban-* Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Tested-by: NMika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: NMika 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 e075a32f) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Chris Wilson 提交于
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: NChris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: NJoonas 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 987046ad) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Ville Syrjälä 提交于
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: ed4a6a7c ("drm/i915: Add two-stage ILK-style watermark programming (v11)") Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NMatt Roper <matthew.d.roper@intel.com> Signed-off-by: NMatt 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 e3d5457c) [Jani: rebase on drm-next while cherry-picking] Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Daniel Vetter 提交于
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: NLyude <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: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Tested-by: fritsch@kodi.tv Signed-off-by: NDaniel 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 50db1390) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Philipp Zabel 提交于
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: NPhilipp Zabel <p.zabel@pengutronix.de> Tested-by: NFabio Estevam <fabio.estevam@nxp.com> Tested-by: NLothar Waßmann <LW@KARO-electronics.de> Tested-by: NHeiko Schocher <hs@denx.de> Tested-by: NChris Ruehl <chris.ruehl@gtsys.com.hk>
-
由 Ramalingam C 提交于
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: NRamalingam C <ramalingam.c@intel.com> Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Acked-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NJani 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 042ab0c3) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Ville Syrjälä 提交于
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: 243e6a44 ("drm/i915: Init HSW watermark tracking in intel_modeset_setup_hw_state()") Cc: stable@vger.kernel.org Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NMatt Roper <matthew.d.roper@intel.com> Signed-off-by: NMatt 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 15606534) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Ville Syrjälä 提交于
SKL DPLLs shouldn't be called DPPLs. Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Fixes: 2edd6443 ("drm/i915: Use a table to initilize shared dplls") Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1462993473-8254-1-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com> (cherry picked from commit d5aab9d4) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Chris Wilson 提交于
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: de1add36 Cc: stable@vger.kernel.org # v4.6 Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: NVille 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 215a7e32) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
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 a8f327fb ("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: a8f327fb ("drm/i915: Clean up CHV lane soft reset programming") Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: NJim 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 d4d6279a) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Ramalingam C 提交于
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: 6f0e7535 ("drm/i915/BXT: Get pipe conf from the port registers") Signed-off-by: NRamalingam C <ramalingam.c@intel.com> Acked-by: NImre Deak <imre.deak@intel.com> Signed-off-by: NJani 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 cefc4e18) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Chris Wilson 提交于
Faced with sporadic machine hangs on gen7, that mimic the issue of concurrent writes to the same cacheline and seem to start with commit 9b9ed309 (drm/i915: Remove forcewake dance from seqno/irq barrier on legacy gen6+), let us restore the spinlock around the mmio read. Fixes: 9b9ed309 (drm/i915: Remove forcewake dance from seqno/irq...) Signed-off-by: NChris 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.ukTested-by: NMika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com> (cherry picked from commit bcbdb6d0) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-