summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2016-04-12i2c: xlp9xx: add support for Broadcom VulcanTanmay Jagdale
The Broadcom Vulcan ARM64 processor uses the same I2C controller present on the Broadcom XLP9xx/5xx MIPS processor family. Updated the Kconfig by adding ARCH_VULCAN option. Signed-off-by: Tanmay Jagdale <tanmay.jagdale@broadcom.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2016-04-12i2c: rk3x: add support for rk3228Yakir Yang
Enable the I2C core for this SoC. Signed-off-by: Yakir Yang <ykk@rock-chips.com> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2016-04-12HID: wacom: Add support for DTK-1651Ping Cheng
DTK-1651 is a display pen-only tablet Signed-off-by: Ping Cheng <pingc@wacom.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2016-04-12Merge tag 'mvebu-fixes-4.6-1' of git://git.infradead.org/linux-mvebu into fixesOlof Johansson
mvebu fixes for 4.6 (part 1) - fix USB adress register for Linksys Armada 388 based boards - fix build warning in mvebu-mbus * tag 'mvebu-fixes-4.6-1' of git://git.infradead.org/linux-mvebu: ARM: mvebu: Correct unit address for linksys bus: mvebu-mbus: use %pa to print phys_addr_t Signed-off-by: Olof Johansson <olof@lixom.net>
2016-04-12ARM: sa1100: remove references to the defunct handhelds.orgLinus Walleij
The website handhelds.org has been down for a long time and is likely never coming back online. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Olof Johansson <olof@lixom.net>
2016-04-12Merge tag 'pxa-fixes-v4.6' of https://github.com/rjarzmik/linux into fixesOlof Johansson
ARM: pxa: fixes for v4.6 There is only a single fix for dma requestor lines initial setup, triggered by dmaengine previous fix. * tag 'pxa-fixes-v4.6' of https://github.com/rjarzmik/linux: ARM: pxa: fix the number of DMA requestor lines Signed-off-by: Olof Johansson <olof@lixom.net>
2016-04-12Merge tag 'omap-for-v4.6/fixes-rc1' of ↵Olof Johansson
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes Fixes for omaps against v4.6-rc1. Mostly minor fixes for the newer SoCs with few board fixes and a fix for a long time hwmod bug: - Fix cpsw_emac0 link type for baltos-ir5221 - Fix interrupt type for TWD - Fix edma memcpy channel allocation for am43x - Fix am43x-epos sycntimer32k by using the correct assigned clock - Fix interconnect barrier for dra7 - Fix a long time hwmod bug for updating sysconfig register properly - Fix flakey booting on dm814x where USB reset needs a delay And there is one minor change that is not strictly a fix, but is good to have for proper hardware detection: - Detect dra7 silicon revision 2.0 properly * tag 'omap-for-v4.6/fixes-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: ARM: dts: am335x-baltos-ir5221: fix cpsw_emac0 link type ARM: OMAP: Correct interrupt type for ARM TWD ARM: DRA722: Add ID detect for Silicon Rev 2.0 ARM: dts: am43xx: fix edma memcpy channel allocation ARM: dts: AM43x-epos: Fix clk parent for synctimer ARM: OMAP2: Fix up interconnect barrier initialization for DRA7 ARM: OMAP2+: hwmod: Fix updating of sysconfig register ARM: OMAP2+: Use srst_udelay for USB on dm814x Signed-off-by: Olof Johansson <olof@lixom.net>
2016-04-12bus: uniphier-system-bus: fix condition of overlap checkKunihiko Hayashi
This patch fixes condition whether the specified address ranges overlap each other. Fixes: 4b7f48d395a7 ("bus: uniphier-system-bus: add UniPhier System Bus driver") Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Olof Johansson <olof@lixom.net>
2016-04-12ARM: uniphier: drop weird sizeof()Masahiro Yamada
My intention was to ioremap a 4-byte register. Coincidentally enough, sizeof(SZ_4) equals to SZ_4, but this code is weird anyway. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Olof Johansson <olof@lixom.net>
2016-04-12drm/i915: Don't read out port_clock on CHV when DPLL is disabledVille Syrjälä
Check whether the DPLL is even enabled before readoing out the dividers and trying to derive port_clock on CHV. We already did this on VLV. Also remove the comment "MIPI" comment from the VLV code since we call this function whenever the pipe is enabled. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1458052809-23426-9-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2016-04-12drm/i915: Dump pfit PGM_RATIOS as hexVille Syrjälä
pgm_ratios in stored as a register value in pipe config, so let's dump this one as hex as well. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1458052809-23426-15-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2016-04-12drm/i915: Fix CHV DSI PLL refclk during state readoutVille Syrjälä
Use the proper refclock frequency (100MHz) when reading out the current DSI clock on CHV. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1458052809-23426-13-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2016-04-12drm/i915: Power down the DSI PLL before reconfiguring itVille Syrjälä
On VLV at least, the BIOS may leave the DSI PLL enabled in some wonky state where it just refuses to lock. Simply disabling the PLL before reconfiguring it is not enough to fix it, but power gating the PLL prior to reconfiguring does work. This happens on BYT FFRD8 when booting with HDMI connected so the DSI display will not be lit up by the BIOS. Also we can remove the code for BXT that disables the PLL before enabling it again. v2: s/vlv/intel/ since BXT made thing generic v3: Remove the BXT disable PLL before enable trick Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1458052809-23426-11-git-send-email-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com>
2016-04-12drm/i915: Change lfsr_converts[] to u16Ville Syrjälä
All the values in the DSI PLL LFSR seed table fit into 9bits, so change the type to u16 from u32 to save a bit of space. drivers/gpu/drm/i915/i915.ko: -.rodata 90824 +.rodata 90760 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1458052809-23426-10-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2016-04-12fscrypto: don't let data integrity writebacks fail with ENOMEMJaegeuk Kim
This patch fixes the issue introduced by the ext4 crypto fix in a same manner. For F2FS, however, we flush the pending IOs and wait for a while to acquire free memory. Fixes: c9af28fdd4492 ("ext4 crypto: don't let data integrity writebacks fail with ENOMEM") Cc: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2016-04-12f2fs: use dget_parent and file_dentry in f2fs_file_openJaegeuk Kim
This patch synced with the below two ext4 crypto fixes together. In 4.6-rc1, f2fs newly introduced accessing f_path.dentry which crashes overlayfs. To fix, now we need to use file_dentry() to access that field. Fixes: c0a37d487884 ("ext4: use file_dentry()") Fixes: 9dd78d8c9a7b ("ext4: use dget_parent() in ext4_file_open()") Cc: Miklos Szeredi <mszeredi@redhat.com> Cc: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2016-04-12fscrypto: use dget_parent() in fscrypt_d_revalidate()Jaegeuk Kim
This patch updates fscrypto along with the below ext4 crypto change. Fixes: 3d43bcfef5f0 ("ext4 crypto: use dget_parent() in ext4_d_revalidate()") Cc: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2016-04-12Revert "drm/i915: Limit the auto arming of mmio debugs on vlv/chv"Ville Syrjälä
Enable the unclaimd register detection stuff on vlv/chv since we've now fixed the known problems during suspend. This reverts commit c81eeea6c14b212016104f4256c65f93ad230a86. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460382992-28728-11-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2016-04-12drm/i915: Move DPINVGTT setup to vlv_display_irq_reset()Ville Syrjälä
DPINVGTT lives inside the disp2d power well so we can't frob it unless we know the power well is active. Let's this stuff into vlv_display_irq_reset() which is only called at the right times so that we don't get unclaimed register access errors. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94164 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460382992-28728-10-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2016-04-12drm/i915: Move vlv_init_display_clock_gating() to the display power wellVille Syrjälä
The registers frobbed by vlv_init_display_clock_gating() libve inside the disp2d power well, so frobbing them while the power well is down results in unclaimed register access warning (and of course the values won't stick). Let's do this setup after we know the power well is enabled. It's also worth noting that DSPCLK_GATE_D and CBR1_VLV lose their state when the power well goes down, but fortunately the values we've been writing are actually the reset defaults. MI_ARB_VLV actually retains its value even if the power well was turned off, we just can't access it while the power well is down. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94164 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460382992-28728-9-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2016-04-12drm/i915: Warn if irq_mask isn't ~0 during vlv/cvh display irq postinstallVille Syrjälä
We expect vlv_display_irq_reset() to have been called prior to vlv_display_irq_postinstall() so let's WARN if that isn't the case. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460382992-28728-8-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2016-04-12drm/i915: Use GEN5_IRQ_INIT() in vlv_display_irq_postinstall()Ville Syrjälä
Replace the hand rolled IMR/IER setup in vlv_display_irq_postinstall() with GEN5_IRQ_INIT(). Also rename the iir_mask to enable_mask to avoid consusion since we no longer deal with IIR here. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460382992-28728-7-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2016-04-12drm/i915: Clear display interrupt before enabling when turning on the power wellVille Syrjälä
For a bit of extra paranoia make sure the display irqs are all cleared before we enabled them when turning on the power well. This should really be the case already since the power well was off which resets everything. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460382992-28728-6-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2016-04-12drm/i915: Move vlv/chv display irq code to a more logical placeVille Syrjälä
Reshuffle the code a bit to move the vlv/chv display irq functions away from the main irq hooks, next to the other sub (de,gt,etc.) hooks. v2: Rebased due to changes in vlv_display_irq_reset() Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> (v1) Link: http://patchwork.freedesktop.org/patch/msgid/1460476604-2035-1-git-send-email-ville.syrjala@linux.intel.com
2016-04-12drm/i915: Skip display irq setup if display irqs aren't flagged as enabledVille Syrjälä
During runtime PM we'll be reinitializing interrupt support from the ground up. However since the display power well will be off at that time, well end up with a ton of unclaimed register accesses from the display irq setup. Since we turned off the power well already before runtime suspend, we've flagged display irqs as disabled during runtime PM transitions. So we can just check that flag to see if we should do skip display irqs during irq setup. During driver load display irqs will be flagged as enabled since we've turned on the power well already, however the power well code will have skipped the display irq setup since irq support as a whole wasn't yet enabled when the power well was enabled. So we'll want to do the display irq setup in that case. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94164 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460382992-28728-4-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2016-04-12drm/i915: Fix up vlv/chv display irq setupVille Syrjälä
The vlv/chv display irq setup was a bit of mess after I ran out of steam when working on it last. Fix it up so that we just have a _reset() and _postinstall() hooks for the display irqs, and use those consistently. v2: Clear out pipestat_irq_mask[] and PIPE_FIFO_UNDERRUN_STATUS in vlv_display_irq_reset() (Imre) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> (v1) Link: http://patchwork.freedesktop.org/patch/msgid/1460476574-1921-1-git-send-email-ville.syrjala@linux.intel.com
2016-04-12drm/i915: Remove "VLV magic" from irq setupVille Syrjälä
No clue what this is supposed to achieve. I think it's been there since the very beginning, so presumably some kind of kludge for very early silicon. Let's just throw it out. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460382992-28728-2-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2016-04-12drm/i915: Replace ILK eDP underrun suppression with something betterVille Syrjälä
The underruns we were seeing when enabling eDP port A on ILK seem to have been caused by prematurely clearing the LP1+ watermark values when disabling LP1+ watermarks. Now that the watermarks are handled properly, we can rip out the underrun suppression around the port A enable. We still need to worry about the underruns on FDI when enabling the eDP PLL. But as Bspec tells us, we can avoid that by a vblank wait on the pipe driving FDI just prior to enabling the eDP PLL. 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/1459536799-18109-4-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
2016-04-12drm/i915: Make sure LP1+ watermarks levels are preserved when going from 1 ↵Ville Syrjälä
to 2 pipes Once again ILK is unhappy if we clear out the LP1+ watermark levels outright, and instead we must disable the levels we don't want while still leaving the actual programmed watermark levels intact. Fixes underruns on the already enabled pipe when programming watermarks while enabling the second pipe. Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Matt Roper <matthew.d.roper@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93787 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459536799-18109-3-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
2016-04-12drm/i915: Try to shut up more ILK underrunsVille Syrjälä
Take a bigger hammer to the underrun suppression on ILK. Instead of trying to suppress them at specific points in the modeset sequence just silence them across the entire sequence. This gets rid of some underruns at least on my ILK. Note that this changes SNB and IVB to follow the same approach just to keep the code less convoluted. The difference is that on those platforms we won't suppress CPU underruns for port A since it doesn't seem to be necessary. My ILK has port A eDP and two PCH HDMI ports, so I can't be sure this is as effective on other PCH port types. Perhaps we still need some of Daniel's extra vblank waits [2]? I've still been able to trigger an underrun on the other pipe, but fixing that perhaps needs the LP1+ disable trick I implemented here [1] which never got merged. A few details which hamper stress testing on my ILK are that sometimes the PCH transcoder gets messed up and refuses to shut down, and sometimes even the panel power sequencer apparently gets stuck on the always on position. [1] https://lists.freedesktop.org/archives/intel-gfx/2014-March/041317.html [2] https://lists.freedesktop.org/archives/intel-gfx/2016-January/086397.html v2: Add a note that we also get underruns when enabling PCH ports Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> (v1) Link: http://patchwork.freedesktop.org/patch/msgid/1459536799-18109-2-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
2016-04-13drm/exynos: Use VIDEO_SAMSUNG_S5P_G2D=n as G2D Kconfig dependencyJavier Martinez Canillas
Commit 254d4d111ee1 ("drm/exynos: Add dependency for G2D in Kconfig") made the DRM_EXYNOS_G2D symbol to only be selectable if the s5p-g2d V4L2 driver is not enabled, since both use the same HW IP block. But added the dependency as depends on !VIDEO_SAMSUNG_S5P_G2D which isn't correct since Kconfig expressions are not boolean but tristate. So it will only evaluate to 'n' if VIDEO_SAMSUNG_S5P_G2D=y but it will evaluate to m if VIDEO_SAMSUNG_S5P_G2D=m. This means that both the V4L2 and DRM drivers can be enabled if the former is enabled as a module, which is not what we want. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2016-04-12drm/i915: Only grab correct forcewake for the engine with execlistsTvrtko Ursulin
Rather than blindly waking up all forcewake domains on command submission, we can teach each engine what is (or are) the correct one to take. On platforms with multiple forcewake domains like VLV, CHV, SKL and BXT, this has the potential of lowering the GPU and CPU power use and submission latency. To implement it we add a function named intel_uncore_forcewake_for_reg whose purpose is to query which forcewake domains need to be taken to read or write a specific register with raw mmio accessors. These enables the execlists engine setup to query which forcewake domains are relevant per engine on the currently running platform. v2: * Kerneldoc. * Split from intel_uncore.c macro extraction, WARN_ON, no warns on old platforms. (Chris Wilson) v3: * Single domain per engine, mention all registers, bi-directional function and a new name, fix handling of gen6 and gen7 writes. (Chris Wilson) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1460468251-14069-1-git-send-email-tvrtko.ursulin@linux.intel.com
2016-04-12drm/i915: Remove forcewake request registers from the shadowed tableTvrtko Ursulin
Chris Wilson points out that we can remove them from the array since they are always written to with raw accessors. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-04-12drm/i915: Extract knowledge of register forcewake domainsTvrtko Ursulin
Knowledge of which register per platform belonds in which forcewake domain was embedded in the MMIO accessors themselves. Extract it into standalone macros so they can be used from new code in the following patches. This causes GCC to compile some of the MMIO accessors slightly differently and grows the code a tiny amount. But none of the growth is on the fast-path so it does not matter hugely. Affected sizes before: 00000000000026f0 00000000000001a5 t gen6_read16 0000000000002390 00000000000001a5 t gen6_read32 00000000000028a0 00000000000001a5 t gen6_read64 00000000000061d0 000000000000019e t gen8_write16 0000000000006510 000000000000019d t gen8_write32 0000000000006370 000000000000019d t gen8_write64 00000000000021f0 000000000000019d t gen8_write8 Affected sizes after: 0000000000002840 00000000000001aa t gen6_read16 00000000000024e0 00000000000001a9 t gen6_read32 00000000000029f0 00000000000001a9 t gen6_read64 0000000000004f20 00000000000001b5 t gen8_write16 0000000000004ba0 00000000000001b4 t gen8_write32 00000000000050e0 00000000000001b4 t gen8_write64 0000000000004d60 00000000000001b4 t gen8_write8 Other MMIO accessors are not affected in size. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-04-12drm/exynos: fix a warning messageDan Carpenter
The "ret = regmap_write()" assignment was missing so this error message is never printed. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2016-04-12drm/exynos: mic: fix an error codeDan Carpenter
We accidentally return success instead of a negative error code here. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2016-04-12drm/exynos: fimd: fix broken dp_clock controlMarek Szyprowski
Commit 1feafd3afd294b03dbbedb8e8f94e0c4db526f10 ("drm/exynos: add exynos5420 support for fimd") add support for Exynos 5420 SoC, but it broke enabling display clock feature because of incorrect condition check. This patch fixes it, so display is working again on platforms requiring display clock control (i.e. Exynos5250-based SNOW platform). Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2016-04-12drm/exynos: build fbdev code conditionallyAndrzej Hajda
Fbdev code should be compiled only if CONFIG_DRM_FBDEV_EMULATION option is enabled. The patch fixes exynos-drm code trying to manipulate fbdev data which is not initialized in case CONFIG_DRM_FBDEV_EMULATION is disabled. Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2016-04-12drm/exynos: fix adjusted_mode pointer in exynos_plane_mode_setAndrzej Hajda
exynos_plane_mode_set should use adjusted_mode from the same atomic state as plane state. Otherwise it will result in incorrect behavior in case crtc mode changes. The patch fixes bug with black console framebuffer in case of command mode panels. Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2016-04-12drm/exynos: fix error handling in exynos_drm_subdrv_openArnd Bergmann
gcc-6 warns about a pointless loop in exynos_drm_subdrv_open: drivers/gpu/drm/exynos/exynos_drm_core.c: In function 'exynos_drm_subdrv_open': drivers/gpu/drm/exynos/exynos_drm_core.c:104:199: error: self-comparison always evaluates to false [-Werror=tautological-compare] list_for_each_entry_reverse(subdrv, &subdrv->list, list) { Here, the list_for_each_entry_reverse immediately terminates because the subdrv pointer is compared to itself as the loop end condition. If we were to take the current subdrv pointer as the start of the list (as we would do if list_for_each_entry_reverse() was not a macro), we would iterate backwards over the &exynos_drm_subdrv_list anchor, which would be even worse. Instead, we need to use list_for_each_entry_continue_reverse() to go back over each subdrv that was successfully opened until the first entry. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2016-04-12nl80211: check netlink protocol in socket release notificationDmitry Ivanov
A non-privileged user can create a netlink socket with the same port_id as used by an existing open nl80211 netlink socket (e.g. as used by a hostapd process) with a different protocol number. Closing this socket will then lead to the notification going to nl80211's socket release notification handler, and possibly cause an action such as removing a virtual interface. Fix this issue by checking that the netlink protocol is NETLINK_GENERIC. Since generic netlink has no notifier chain of its own, we can't fix the problem more generically. Fixes: 026331c4d9b5 ("cfg80211/mac80211: allow registering for and sending action frames") Cc: stable@vger.kernel.org Signed-off-by: Dmitry Ivanov <dima@ubnt.com> [rewrite commit message] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2016-04-12drm/i915: Do not serialize forcewake acquire across domainsTvrtko Ursulin
On platforms with multiple forcewake domains it seems more efficient to request all desired ones and then to wait for acks to avoid needlessly serializing on each domain. v2: Rebase. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1460045074-1006-1-git-send-email-tvrtko.ursulin@linux.intel.com
2016-04-12drm/i915: Simplify for_each_fw_domain iteratorsTvrtko Ursulin
As the vast majority of users do not use the domain id variable, we can eliminate it from the iterator and also change the latter using the same principle as was recently done for for_each_engine. For a couple of callers which do need the domain mask, store it in the domain array (which already has the domain id), then both can be retrieved thence. Result is clearer code and smaller generated binary, especially in the tight fw get/put loops. Also, relationship between domain id and mask is no longer assumed in the macro. v2: Improve grammar in the commit message and rename the iterator to for_each_fw_domain_masked for consistency. (Dave Gordon) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Dave Gordon <david.s.gordon@intel.com>
2016-04-12drm/i915: Use consistent forcewake auto-release timeout across kernel configsTvrtko Ursulin
Because it is based on jiffies, current implementation releases the forcewake at any time between straight away and between 1ms and 10ms, depending on the kernel configuration (CONFIG_HZ). This is probably not what has been desired, since the dynamics of keeping parts of the GPU awake should not be correlated with this kernel configuration parameter. Change the auto-release mechanism to use hrtimers and set the timeout to 1ms with a 1ms of slack. This should make the GPU power consistent across kernel configs, and timer slack should enable some timer coalescing where multiple force-wake domains exist, or with unrelated timers. For GlBench/T-Rex this decreases the number of forcewake releases from ~480 to ~300 per second, and for a heavy combined OGL/OCL test from ~670 to ~360 (HZ=1000 kernel). Even though this reduction can be attributed to the average release period extending from 0-1ms to 1-2ms, as discussed above, it will make the forcewake timeout consistent for different CONFIG_HZ values. Real life measurements with the above workload has shown that, with this patch, both manage to auto-release the forcewake between 2-4 times per 10ms, even though the number of forcewake gets is dramatically different. T-Rex requests between 5-10 explicit gets and 5-10 implict gets in each 10ms period, while the OGL/OCL test requests 250 and 380 times in the same period. The two data points together suggest that the nature of the forwake accesses is bursty and that further changes and potential timeout extensions, or moving the start of timeout from the first to the last automatic forcewake grab, should be carefully measured for power and performance effects. v2: * Commit spelling. (Dave Gordon) * More discussion on numbers in the commit. (Chris Wilson) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Dave Gordon <david.s.gordon@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-04-12drm/virtio: Drop dummy gamma table supportDaniel Vetter
No need to confuse userspace like this. Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Dave Airlie <airlied@redhat.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459331485-28376-8-git-send-email-daniel.vetter@ffwll.ch
2016-04-12drm/bochs: Drop fake gamma supportDaniel Vetter
Only really needed for fbdev emulation at 8bpp. And bochs doesn't do that. And either way bochs only does 32bit rgb, so this is all pretty much wasted dead code. The only consideration is that we need to not set up any gamma size either. Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Dave Airlie <airlied@redhat.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459331485-28376-5-git-send-email-daniel.vetter@ffwll.ch
2016-04-12drm/core: Fix ordering in drm_mode_config_cleanup.Maarten Lankhorst
__drm_atomic_helper_plane_destroy_state calls drm_framebuffer_unreference, which means that if drm_framebuffer_free is called before plane->destroy freed memory will be accessed. A similar case happens for the blob list, which was freed before the crtc state was, resulting in the unreference_blob from crtc_destroy_state pointing to garbage memory causing another opportunity for a GPF. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1458657734-21866-1-git-send-email-maarten.lankhorst@linux.intel.com
2016-04-12drm/i915: Get panel_type from OpRegion panel detailsVille Syrjälä
We've had problems on several occasions with using the panel type from the VBT block 40. Usually it seems to be 2, which often doesn't give us the correct timings for the panel. After some more digging I found a way to get a panel type via the OpRegion SWSCI GBDA "Get Panel Details" method. Let's try to use it. The spec has this to say about the output: "Bits [15:8] - Panel Type Bits contain the panel type user setting from CMOS 00h = Not Valid, use default Panel Type & Timings from VBT 01h - 0Fh = Panel Number" Another version of the spec lists the valid range as 1-16, which makes more sense since VBT supports 16 panels. Based on actual results from Rob's G45, 1-16 is what we need to accept. The other bits in the output don't look relevant for the problem at hand. The input is specified as: "Bits [31:4] - Reserved Reserved (must be zero) Bits [3:0] - Panel Number These bits contain the sequential index of Panel, starting at 0 and counting upwards from the first integrated Internal Flat-Panel Display Encoder present, and then from the first external Display Encoder (e.g., S/DVO-B then S/DVO-C) which supports Internal Flat-Panels. 0h - 0Fh = Panel number" For now I've just hardcoded the input panel number as 0. That would seem like a decent choise for LVDS. Not so sure about eDP when port != A. v2: Accept values 1-16 Filter out bogus results in opregion code (Jani) Add debug logging for all the different branches (Jani) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Rob Kramer <rob@solution-space.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94825 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460359431-11003-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com> Tested-by: Rob Kramer <rob@solution-space.com>
2016-04-12drm/i915: Replace the static panel_type variable with dev_priv->vbt.panel_typeVille Syrjälä
Store the extracted panel_type under dev_priv.vbt instead of keeping around a static variable for it. Cc: Rob Kramer <rob@solution-space.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2016-04-12drm/i915: Reject panel_type > 0xf from VBTVille Syrjälä
VBT can only contain 16 panel entries, indexed with the panel_type. To play it safe we should reject panel_type > 0xf, so that we don't read past the valid data. v2: Add debug logging (Jani) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Rob Kramer <rob@solution-space.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> (v1) Link: http://patchwork.freedesktop.org/patch/msgid/1460359329-10817-1-git-send-email-ville.syrjala@linux.intel.com