aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2016-05-23ASoC: kirkwood: fix build failureSudip Mukherjee1-0/+1
While building m32r allmodconfig the build failed with: ERROR: "bad_dma_ops" [sound/soc/kirkwood/snd-soc-kirkwood.ko] undefined! To satisfy the dependency CONFIG_SND_KIRKWOOD_SOC should depend on HAS_DMA. Signed-off-by: Sudip Mukherjee <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2016-05-23Fix typoAndrea Gelmini1-2/+2
Signed-off-by: Andrea Gelmini <[email protected]> Signed-off-by: Chris Metcalf <[email protected]>
2016-05-23Fix typoAndrea Gelmini1-2/+2
Signed-off-by: Andrea Gelmini <[email protected]> Signed-off-by: Chris Metcalf <[email protected]>
2016-05-23Fix typoAndrea Gelmini1-1/+1
Signed-off-by: Andrea Gelmini <[email protected]> Signed-off-by: Chris Metcalf <[email protected]>
2016-05-23sunrpc: fix stripping of padded MIC tokensTomáš Trnka1-2/+2
The length of the GSS MIC token need not be a multiple of four bytes. It is then padded by XDR to a multiple of 4 B, but unwrap_integ_data() would previously only trim mic.len + 4 B. The remaining up to three bytes would then trigger a check in nfs4svc_decode_compoundargs(), leading to a "garbage args" error and mount failure: nfs4svc_decode_compoundargs: compound not properly padded! nfsd: failed to decode arguments! This would prevent older clients using the pre-RFC 4121 MIC format (37-byte MIC including a 9-byte OID) from mounting exports from v3.9+ servers using krb5i. The trimming was introduced by commit 4c190e2f913f ("sunrpc: trim off trailing checksum before returning decrypted or integrity authenticated buffer"). Fixes: 4c190e2f913f "unrpc: trim off trailing checksum..." Signed-off-by: Tomáš Trnka <[email protected]> Cc: [email protected] Acked-by: Jeff Layton <[email protected]> Signed-off-by: J. Bruce Fields <[email protected]>
2016-05-23svcrpc: autoload rdma moduleJ. Bruce Fields1-4/+19
This should fix failures like: # rpc.nfsd --rdma rpc.nfsd: Unable to request RDMA services: Protocol not supported Reported-by: Steve Dickson <[email protected]> Reviewed-by: Chuck Lever <[email protected]> Signed-off-by: J. Bruce Fields <[email protected]>
2016-05-23perf report: Add srcline_from/to branch sort keysAndi Kleen6-1/+101
Add "srcline_from" and "srcline_to" branch sort keys that allow to show the source lines of a branch. That makes it much easier to track down where particular branches happen in the program, for example to examine branch mispredictions, or to associate it with cycle counts: % perf record -b -e cycles:p ./tcall % perf report --sort srcline_from,srcline_to,mispredict ... 15.10% tcall.c:18 tcall.c:10 N 14.83% tcall.c:11 tcall.c:5 N 14.12% tcall.c:7 tcall.c:12 N 14.04% tcall.c:12 tcall.c:5 N 12.42% tcall.c:17 tcall.c:18 N 12.39% tcall.c:7 tcall.c:13 N 12.27% tcall.c:13 tcall.c:17 N ... % perf report --sort srcline_from,srcline_to,cycles ... 17.12% tcall.c:18 tcall.c:11 1 17.01% tcall.c:12 tcall.c:6 1 16.98% tcall.c:11 tcall.c:6 1 15.91% tcall.c:17 tcall.c:18 1 6.38% tcall.c:7 tcall.c:17 7 4.80% tcall.c:7 tcall.c:12 8 4.21% tcall.c:7 tcall.c:17 8 2.67% tcall.c:7 tcall.c:12 7 2.62% tcall.c:7 tcall.c:12 10 2.10% tcall.c:7 tcall.c:17 9 1.58% tcall.c:7 tcall.c:12 6 1.44% tcall.c:7 tcall.c:12 5 1.38% tcall.c:7 tcall.c:12 9 1.06% tcall.c:7 tcall.c:17 13 1.05% tcall.c:7 tcall.c:12 4 1.01% tcall.c:7 tcall.c:17 6 Open issues: - Some kernel symbols get misresolved. Signed-off-by: Andi Kleen <[email protected]> Acked-by: Jiri Olsa <[email protected]> Tested-by: Arnaldo Carvalho de Melo <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2016-05-23ftracetest: Use proper logic to find process PIDSteven Rostedt (Red Hat)1-10/+5
Half of the test in instance-event.tc was updated to use $! to find the PID of the previous background process that was launched, but the second part of the test still used the parsing of "jobs", which does not work on all shells like $! does. Signed-off-by: Steven Rostedt <[email protected]>
2016-05-23drm/i915: Stop automatically retiring requests after a GPU hangChris 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 <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Mika Kuoppala <[email protected]> Tested-by: Mika Kuoppala <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit e075a32f515becef66dc849f5eca47409ccf5473) Signed-off-by: Jani Nikula <[email protected]>
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 <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Reviewed-by: Joonas Lahtinen <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 987046ad65361a8b038fbf8d76d152237fb7acf1) Signed-off-by: Jani Nikula <[email protected]>
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 <[email protected]> Cc: Maarten Lankhorst <[email protected]> Fixes: ed4a6a7ca853 ("drm/i915: Add two-stage ILK-style watermark programming (v11)") Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Matt Roper <[email protected]> Signed-off-by: Matt Roper <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit e3d5457c7caabb77b3f1d0b09c4a63362e9b04d2) [Jani: rebase on drm-next while cherry-picking] Signed-off-by: Jani Nikula <[email protected]>
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 <[email protected]> Cc: Lyude <[email protected]> Cc: [email protected] Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95176 Cc: Rodrigo Vivi <[email protected]> Cc: Sonika Jindal <[email protected]> Cc: Durgadoss R <[email protected]> Cc: "Pandiyan, Dhinakaran" <[email protected]> Tested-by: Ville Syrjälä <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Tested-by: [email protected] Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 50db139018f9c94376d5f4db94a3bae65fdfac14) Signed-off-by: Jani Nikula <[email protected]>
2016-05-23Merge tag 'keys-next-20160511' of ↵James Morris2-1/+13
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs into for-linus
2016-05-23Merge remote-tracking branch 'spi/topic/zynqmp' into spi-nextMark Brown1-1/+2
2016-05-23Merge remote-tracking branches 'spi/topic/pxa2xx', 'spi/topic/qup', ↵Mark Brown8-35/+50
'spi/topic/rockchip', 'spi/topic/st-ssc4' and 'spi/topic/xlp' into spi-next
2016-05-23Merge remote-tracking branches 'spi/topic/octeon', 'spi/topic/omap2-mcspi', ↵Mark Brown8-77/+1697
'spi/topic/orion', 'spi/topic/pic32' and 'spi/topic/pic32-qspi' into spi-next
2016-05-23Merge remote-tracking branches 'spi/topic/dw', 'spi/topic/flash-read', ↵Mark Brown6-11/+39
'spi/topic/fsl-dspi', 'spi/topic/fsl-espi' and 'spi/topic/kconfig' into spi-next
2016-05-23Merge remote-tracking branches 'spi/topic/bcm53xx', 'spi/topic/cadence', ↵Mark Brown6-162/+240
'spi/topic/davinci' and 'spi/topic/dln2' into spi-next
2016-05-23Merge remote-tracking branch 'spi/topic/core' into spi-nextMark Brown1-2/+5
2016-05-23drm/imx: Match imx-ipuv3-crtc components using device node in platform dataPhilipp Zabel4-3/+14
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: <[email protected]> # 4.4.x Fixes: 950b410dd1ab ("gpu: ipu-v3: Fix imx-ipuv3-crtc module autoloading") Signed-off-by: Philipp Zabel <[email protected]> Tested-by: Fabio Estevam <[email protected]> Tested-by: Lothar Waßmann <[email protected]> Tested-by: Heiko Schocher <[email protected]> Tested-by: Chris Ruehl <[email protected]>
2016-05-23mmc: sdhci-acpi: Remove MMC_CAP_BUS_WIDTH_TEST for Intel controllersAdrian Hunter1-3/+3
The CMD19/CMD14 bus width test has been found to be unreliable in some cases. It is not essential, so simply remove it. Signed-off-by: Adrian Hunter <[email protected]> Cc: [email protected] Signed-off-by: Ulf Hansson <[email protected]>
2016-05-23mmc: sdhci-pci: Remove MMC_CAP_BUS_WIDTH_TEST for Intel controllersAdrian Hunter1-4/+1
The CMD19/CMD14 bus width test has been found to be unreliable in some cases. It is not essential, so simply remove it. Signed-off-by: Adrian Hunter <[email protected]> Cc: [email protected] Signed-off-by: Ulf Hansson <[email protected]>
2016-05-23mmc: longer timeout for long read time quirkMatt Gumbel2-4/+5
008GE0 Toshiba mmc in some Intel Baytrail tablets responds to MMC_SEND_EXT_CSD in 450-600ms. This patch will... () Increase the long read time quirk timeout from 300ms to 600ms. Original author of that quirk says 300ms was only a guess and that the number may need to be raised in the future. () Add this specific MMC to the quirk Signed-off-by: Matt Gumbel <[email protected]> Signed-off-by: Adrian Hunter <[email protected]> Cc: [email protected] Signed-off-by: Ulf Hansson <[email protected]>
2016-05-23mmc: dw_mmc: rockchip: Set the drive phase properlyDouglas Anderson1-0/+64
Historically for Rockchip devices we've relied on the power-on default (or perhaps the firmware setting) to get the correct drive phase for dw_mmc devices. This worked OK for the most part, but: * Relying on the setting just "being right" is a bit fragile. * As soon as there is an instance where the power on default is wrong or where the firmware didn't configure this properly then we'll get a mysterious failure. In commit 7a03fe6f48f3 ("clk: rockchip: reset init state before mmc card initialization") we actually started setting this explicitly in the kernel, but that commit wasn't quite right and also wasn't quite enough. See <https://patchwork.kernel.org/patch/9085311/> for some details. Let's explicitly set this phase in dw_mmc. The comments inside this patch try to explain the situation quite throughly, but the high level overview of this is: Before this patch on rk3288 devices tested (after revert of the clock patch described above): * eMMC: 180 degrees * SDMMC/SDIO0/SDIO1: 90 degrees After this patch: * Use 90 degree phase offset usually. * Use 180 degree phase offset for MMC_DDR52, SDR104, HS200. That means we are _changing_ behavior for those devices in this way: * If we have HS200 eMMC or DDR52 eMMC, we'll run ID mode at 90 degrees (vs 180) but otherwise have no change. * For any non-HS200 / non-DDR52 eMMC devices we'll now _always_ run at 90 degrees (vs 180). It seems fairly unlikely that building modern hardware is using an eMMC that isn't using DDR52 or HS200, of course. * For SDR104 cards we'll now run with 180 degree phase offset (vs 90). It's expected that 90 degree phase offset would have worked OK, but this gives us extra margin. I have tested this by inserting my collection of uSD cards (mostly UHS, though a few not) into a veyron_minnie and confirmed that they still seem to enumerate properly. For a subset of them I tried putting a filesystem on them and also tried running mmc_test. Fixes: 7a03fe6f48f3 ("clk: rockchip: reset init state before mmc card initialization") Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Shawn Lin <[email protected]> Tested-by: Heiko Stuebner <[email protected]> Tested-by: Enric Balletbo i Serra <[email protected]> Signed-off-by: Jaehoon Chung <[email protected]> Signed-off-by: Ulf Hansson <[email protected]>
2016-05-23mmc: dw_mmc: fix the wrong max_blk_sizeJaehoon Chung1-3/+3
According to DesignWare TRM, BLKSIZ is 16bits. Then it's correct that max_blk_size should be 0xFFFF, not 0x10000. Signed-off-by: Jaehoon Chung <[email protected]> Reviewed-by: Shawn Lin <[email protected]> Signed-off-by: Ulf Hansson <[email protected]>
2016-05-23mmc: dw_mmc-rockchip: add MMC_CAP_CMD23 capabilitiesShawn Lin1-4/+4
Add MMC_CAP_CMD23 for dw_mmc-rockchip, otherwise failing to create rpmb partition. With it, we can get rpmb successfully: mmc1: new HS200 MMC card at address 0001 mmcblk0: mmc1:0001 DS2016 14.7 GiB mmcblk0boot0: mmc1:0001 DS2016 partition 1 4.00 MiB mmcblk0boot1: mmc1:0001 DS2016 partition 2 4.00 MiB mmcblk0rpmb: mmc1:0001 DS2016 partition 3 4.00 MiB Signed-off-by: Shawn Lin <[email protected]> Signed-off-by: Jaehoon Chung <[email protected]> Signed-off-by: Ulf Hansson <[email protected]>
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 <[email protected]> Acked-by: Daniel Vetter <[email protected]> Acked-by: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 042ab0c3c40be1efcaad6b526173b5536fc6c3bf) Signed-off-by: Jani Nikula <[email protected]>
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 <[email protected]> Fixes: 243e6a44b9ca ("drm/i915: Init HSW watermark tracking in intel_modeset_setup_hw_state()") Cc: [email protected] Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Matt Roper <[email protected]> Signed-off-by: Matt Roper <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 15606534bf0a65d8a74a90fd57b8712d147dbca6) Signed-off-by: Jani Nikula <[email protected]>
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 <[email protected]> Fixes: 2edd6443e3d0 ("drm/i915: Use a table to initilize shared dplls") Signed-off-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Ander Conselvan de Oliveira <[email protected]> (cherry picked from commit d5aab9d40135725cbe81ed5e3af5209382063193) Signed-off-by: Jani Nikula <[email protected]>
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: [email protected] # v4.6 Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Cc: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 215a7e3210eb208abe634480741e418b5a8bf60c) Signed-off-by: Jani Nikula <[email protected]>
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 <[email protected]> Reviewed-by: Jim Bride <[email protected]> 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 <[email protected]>
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 <[email protected]> Acked-by: Imre Deak <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit cefc4e18785123326c5d4d985085e32160fef7f5) Signed-off-by: Jani Nikula <[email protected]>
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 <[email protected]> Cc: Mika Kuoppala <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Tested-by: Mika Kuoppala <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> (cherry picked from commit bcbdb6d01150dcc1769ddc9baaaf7f102f27f919) Signed-off-by: Jani Nikula <[email protected]>
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 <[email protected]> Cc: [email protected] Fixes: ebb7c78d358b ("agp/intel-gtt: Only register fake agp driver for gen1") Signed-off-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Chris Wilson <[email protected]> (cherry picked from commit ac840ae53573d9f435c88c131f6707a79aecb466) Signed-off-by: Jani Nikula <[email protected]>
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: [email protected] Cc: Tore Anderson <[email protected]> Reported-by: Tore Anderson <[email protected]> Fixes: 7a0baa623446 ("Revert "drm/i915: Disable 12bpc hdmi for now"") Cc: Paulo Zanoni <[email protected]> Cc: Shashank Sharma <[email protected]> Cc: Daniel Vetter <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Shashank Sharma <[email protected]> (cherry picked from commit d61992565bd3cc5b66d74ed2e96df043c2a207e2) Signed-off-by: Jani Nikula <[email protected]>
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: [email protected] Cc: Tore Anderson <[email protected]> Cc: Paulo Zanoni <[email protected]> Cc: Shashank Sharma <[email protected]> Cc: Daniel Vetter <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Shashank Sharma <[email protected]> (cherry picked from commit b2ccb822d376d1bbbe5d1f9118d1488b25e6bc6d) Signed-off-by: Jani Nikula <[email protected]>
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: [email protected] Reported-by: Tore Anderson <[email protected]> Fixes: 7a0baa623446 ("Revert "drm/i915: Disable 12bpc hdmi for now"") Cc: Paulo Zanoni <[email protected]> Cc: Shashank Sharma <[email protected]> Cc: Daniel Vetter <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Shashank Sharma <[email protected]> (cherry picked from commit b1ba124d8e95cca48d33502a4a76b1ed09d213ce) Signed-off-by: Jani Nikula <[email protected]>
2016-05-23drm: Add helper for DP++ adaptorsVille Syrjälä4-1/+465
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: [email protected] Cc: Tore Anderson <[email protected]> Cc: Paulo Zanoni <[email protected]> Cc: Shashank Sharma <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Shashank Sharma <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Shashank Sharma <[email protected]> (v4) Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit ede53344dbfd1dd43bfd73eb6af743d37c56a7c3) Signed-off-by: Jani Nikula <[email protected]>
2016-05-23MAINTAINERS: Add file patterns for watchdog device tree bindingsGeert Uytterhoeven1-0/+1
Submitters of device tree binding documentation may forget to CC the subsystem maintainer if this is missing. Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Wim Van Sebroeck <[email protected]> Cc: [email protected]
2016-05-22Merge tag 'trace-v4.7-2' of ↵Linus Torvalds3-4/+147
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace Pull motr tracing updates from Steven Rostedt: "Three more changes. - I forgot that I had another selftest to stress test the ftrace instance creation. It was actually suppose to go into the 4.6 merge window, but I never committed it. I almost forgot about it again, but noticed it was missing from your tree. - Soumya PN sent me a clean up patch to not disable interrupts when taking the tasklist_lock for read, as it's unnecessary because that lock is never taken for write in irq context. - Newer gcc's can cause the jump in the function_graph code to the global ftrace_stub label to be a short jump instead of a long one. As that jump is dynamically converted to jump to the trace code to do function graph tracing, and that conversion expects a long jump it can corrupt the ftrace_stub itself (it's directly after that call). One way to prevent gcc from using a short jump is to declare the ftrace_stub as a weak function, which we do here to keep gcc from optimizing too much" * tag 'trace-v4.7-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace: ftrace/x86: Set ftrace_stub to weak to prevent gcc from using short jumps to it ftrace: Don't disable irqs when taking the tasklist_lock read_lock ftracetest: Add instance created, delete, read and enable event test
2016-05-22Merge branch 'for-next' of ↵Linus Torvalds1-1/+2
git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu Pull m68knommu update from Greg Ungerer: "Only a single change to update my email address in the MAINTAINERS file" * 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu: m68k: change m68knommu maintainer email address
2016-05-22Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparcLinus Torvalds19-110/+147
Pull sparc updates from David Miller: "Some 32-bit kgdb cleanups from Sam Ravnborg, and a hugepage TLB flush overhead fix on 64-bit from Nitin Gupta" * git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc: sparc64: Reduce TLB flushes during hugepte changes aeroflex/greth: fix warning about unused variable openprom: fix warning sparc32: drop superfluous cast in calls to __nocache_pa() sparc32: fix build with STRICT_MM_TYPECHECKS sparc32: use proper prototype for trapbase sparc32: drop local prototype in kgdb_32 sparc32: drop hardcoding trap_level in kgdb_trap
2016-05-23drm/edid: add displayid detailed 1 timings to the modelist. (v1.1)Dave Airlie2-0/+125
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 <[email protected]>
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 <[email protected]>
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 <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
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 <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
2016-05-22x86: remove more uaccess_32.h complexityLinus Torvalds4-31/+3
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_from_user_inatomic()" is mostly the special cases for the constant size, and it's actually almost never relevant. Most users aren't actually using a constant size anyway, and the few cases that do small constant copies are better off just using __get_user() instead. So get rid of the unnecessary complexity. Signed-off-by: Linus Torvalds <[email protected]>
2016-05-22x86: remove pointless uaccess_32.h complexityLinus Torvalds2-39/+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 <[email protected]>
2016-05-22parisc: Fix typo in fpudispatch.cAndrea Gelmini1-1/+1
Signed-off-by: Andrea Gelmini <[email protected]> Signed-off-by: Helge Deller <[email protected]>
2016-05-22parisc: Fix typos in eisa_eeprom.hAndrea Gelmini1-2/+2
Signed-off-by: Andrea Gelmini <[email protected]> Signed-off-by: Helge Deller <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.