summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2016-05-11drm/sti: include linux/seq_file.h where neededArnd Bergmann
The sti drm driver has a lot of debugfs interface that cause build errors in some configurations when seq_file.h is not included implicitly: drm/sti/sti_mixer.c: In function 'mixer_dbg_ctl': drm/sti/sti_mixer.c:88:2: error: implicit declaration of function 'seq_puts' [-Werror=implicit-function-declaration] drm/sti/sti_mixer.c:91:4: error: implicit declaration of function 'seq_printf' [-Werror=implicit-function-declaration] drm/sti/sti_gdp.c: In function 'gdp_dbg_ctl': drm/sti/sti_gdp.c:146:2: error: implicit declaration of function 'seq_puts' [-Werror=implicit-function-declaration] drm/sti/sti_gdp.c:149:4: error: implicit declaration of function 'seq_printf' [-Werror=implicit-function-declaration] drm/sti/sti_gdp.c: In function 'gdp_dbg_show': drm/sti/sti_gdp.c:208:32: error: dereferencing pointer to incomplete type 'struct seq_file' This adds an explicit #include statement in all of the affected files. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1462830733-1710590-2-git-send-email-arnd@arndb.de
2016-05-11drm/tegra: Use lockless gem BO free callbackDaniel Vetter
No dev->struct_mutex anywhere to be seen. Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Terje Bergström <tbergstrom@nvidia.com> Cc: linux-tegra@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1461691808-12414-28-git-send-email-daniel.vetter@ffwll.ch
2016-05-10drm/i915: Use drm_i915_private as the native pointer for intel_uncore.cChris Wilson
Pass drm_i915_private to the uncore init/fini routines and their subservients as it is their native type. text data bss dec hex filename 6309978 3578778 696320 10585076 a183f4 vmlinux 6309530 3578778 696320 10584628 a18234 vmlinux a modest 400 bytes of saving, but 60 lines of code deleted! Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1462885804-26750-1-git-send-email-chris@chris-wilson.co.uk
2016-05-10drm/exynos/decon5433: fix trigger configurationAndrzej Hajda
It seems trigger cannot be configured too early, otherwise it does not work in case of panel. The patch fixes also trigger flag logic, previously HW-TRIGGER flag was cleared in case of panel - as a result panel used always software trigger. Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2016-05-10drm/exynos/dsi: use of_graph_get_endpoint_by_regs helperPhilipp Zabel
This allows to remove the local of_graph_get_port_by_reg(), of_graph_get_endpoint_by_reg(), and of_get_child_by_name_reg() functions. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Reviewed-by: Inki Dae <inki.dae@samsung.com>
2016-05-10drm/exynos/dpi: use of_graph_get_endpoint_by_regs helperPhilipp Zabel
This allows to remove the local of_graph_get_port_by_reg(), of_graph_get_endpoint_by_reg(), of_get_child_by_name_reg(), and of_graph_get_remote_port_parent() functions. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2016-05-10drm/exynos: Nuke dummy fb->dirty callbackDaniel Vetter
It's an optional hook. Might be needed for frontbuffer rendering on manual upload displays, but a simple TODO doesn't explain at all what needs to be done or why. Cc: Inki Dae <inki.dae@samsung.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2016-05-10drm/exynos: use directly DMA mapping APIs on g2dJoonyoung Shim
There is no reason to be wapper functions to use DMA mapping APIs. Use directly DMA mapping APIs and remove the wapper functions. Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2016-05-10drm/exynos/hdmi: Don't print error on deferral due to regulatorsJavier Martinez Canillas
The regulators may not be available just because their driver's probe function was just not executed and so the regulators not registered. So, in this case the Exynos HDMI driver should not print logs since a -EPROBE_DEFER is not really an error and that will just pollute the kernel log and confuse users. This patch prevents the following misleading messages to be printed: [ 1.443638] [drm:hdmi_probe] *ERROR* failed to get regulators [ 1.449326] [drm:hdmi_probe] *ERROR* hdmi_resources_init failed Reported-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2016-05-10drm/exynos: fix imported dma-buf to be mappedJoonyoung Shim
The imported dma-buf should be mapped by sub-system exporting it. Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2016-05-10drm/exynos: support gem_prime_mmapJoonyoung Shim
This allows exported dma-bufs to be mapped using gem_prime_mmap. Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2016-05-10drm/exynos: fimd: harden fimd_calc_clkdiv()Tobias Jakobi
Don't use the vrefresh field of the DRM mode since this one is supposed to only be used for debug purpose. Instead use the clock field which should also provide much more precise information. Also sanitize the case in which the clock value should be zero. We then just default to the maximum clock divisor. Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2016-05-10drm/exynos: fix cancel page flip codeAndrzej Hajda
Driver code did not remove event from the list of pending events before destroy. As a result drm core later tried to inspect invalid memory location. The patch replaces removal code with call to core helper. The bug was detected using KASAN: [ 10.107249] ================================================================== [ 10.107518] BUG: KASAN: use-after-free in drm_release+0xe9c/0x1000 at addr ffffffc089154a18 [ 10.107784] Read of size 8 by task modetest/103 [ 10.107931] ============================================================================= [ 10.113191] BUG kmalloc-128 (Not tainted): kasan: bad access detected [ 10.119608] ----------------------------------------------------------------------------- [ 10.119608] [ 10.129243] Disabling lock debugging due to kernel taint [ 10.134551] INFO: Allocated in drm_mode_page_flip_ioctl+0x500/0xa98 age=4 cpu=0 pid=103 [ 10.142532] alloc_debug_processing+0x18c/0x198 [ 10.147043] ___slab_alloc.constprop.28+0x360/0x380 [ 10.151906] __slab_alloc.isra.25.constprop.27+0x54/0xa0 [ 10.157197] kmem_cache_alloc_trace+0x370/0x3b0 [ 10.161709] drm_mode_page_flip_ioctl+0x500/0xa98 [ 10.166400] drm_ioctl+0x4c4/0xb68 [ 10.169787] do_vfs_ioctl+0x16c/0xeb8 [ 10.173429] SyS_ioctl+0x8c/0xa0 [ 10.176642] el0_svc_naked+0x24/0x28 [ 10.180204] INFO: Freed in exynos_drm_crtc_cancel_page_flip+0xe0/0x160 age=0 cpu=0 pid=103 [ 10.188447] free_debug_processing+0x174/0x388 [ 10.192871] __slab_free+0x2e8/0x438 [ 10.196431] kfree+0x350/0x360 [ 10.199469] exynos_drm_crtc_cancel_page_flip+0xe0/0x160 [ 10.204762] exynos_drm_preclose+0x58/0xa0 [ 10.208844] drm_release+0x1f0/0x1000 [ 10.212491] __fput+0x1c4/0x5b8 [ 10.215613] ____fput+0xc/0x18 [ 10.218654] task_work_run+0x130/0x198 [ 10.222385] do_exit+0x700/0x2278 [ 10.225681] do_group_exit+0xe4/0x2c8 [ 10.229327] SyS_exit_group+0x1c/0x20 [ 10.232973] el0_svc_naked+0x24/0x28 [ 10.236532] INFO: Slab 0xffffffbdc2a45500 objects=32 used=10 fp=0xffffffc089154a00 flags=0x4080 [ 10.245210] INFO: Object 0xffffffc089154a00 @offset=2560 fp=0xffffffc089157600 [ 10.245210] ... [ 10.384532] CPU: 0 PID: 103 Comm: modetest Tainted: G B 4.5.0-rc3-00748-gd5e2881 #271 [ 10.398325] Call trace: [ 10.400764] [<ffffffc000091428>] dump_backtrace+0x0/0x328 [ 10.406141] [<ffffffc000091764>] show_stack+0x14/0x20 [ 10.411176] [<ffffffc00089c550>] dump_stack+0xb0/0xe8 [ 10.416210] [<ffffffc000395778>] print_trailer+0xf8/0x160 [ 10.421592] [<ffffffc00039b5cc>] object_err+0x3c/0x50 [ 10.426626] [<ffffffc00039d630>] kasan_report_error+0x248/0x550 [ 10.432527] [<ffffffc00039da50>] __asan_report_load8_noabort+0x40/0x48 [ 10.439039] [<ffffffc000b5b724>] drm_release+0xe9c/0x1000 [ 10.444419] [<ffffffc0003d340c>] __fput+0x1c4/0x5b8 [ 10.449280] [<ffffffc0003d3884>] ____fput+0xc/0x18 [ 10.454055] [<ffffffc000101aa8>] task_work_run+0x130/0x198 [ 10.459522] [<ffffffc0000bc058>] do_exit+0x700/0x2278 [ 10.464557] [<ffffffc0000bdcfc>] do_group_exit+0xe4/0x2c8 [ 10.469939] [<ffffffc0000bdefc>] SyS_exit_group+0x1c/0x20 [ 10.475320] [<ffffffc000087530>] el0_svc_naked+0x24/0x28 Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2016-05-10drm/exynos/decon5433: do not use unnecessary software triggerAndrzej Hajda
Software trigger should not be used if hardware trigger is configured. Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2016-05-10drm/exynos/decon5433: handle vblank in vblank interruptAndrzej Hajda
vblank should be signaled to userspace after reading framebuffers not before, signaling it in TE interrupt looks wrong. TE triggers reading framebuffers so it is the worst moment. Tearing is not observable because hardware prevents it, but there are frequently skipped vblank events. Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2016-05-10drm/exynos/hdmi: expose HDMI-PHY clock as pipeline clockAndrzej Hajda
HDMI-PHY clock should be accessible from other components in the pipeline. Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2016-05-10drm/i915: Re-enable GGTT earlier during resume on pre-gen6 platformsVille Syrjälä
Move the intel_enable_gtt() call to happen before we touch the GTT during resume. Right now it's done way too late. Before commit ebb7c78d358b ("agp/intel-gtt: Only register fake agp driver for gen1") it was actually done earlier on account of also getting called from the resume hook of the fake agp driver. With the fake agp driver no longer getting registered we must move the call up. The symptoms I've seen on my 830 machine include lowmem corruption, other kinds of memory corruption, and straight up hung machine during or just after resume. Not really sure what causes the memory corruption, but so far I've not seen any with this fix. I think we shouldn't really need to call this during init, but we have been doing that so I've decided to keep the call. However moving that call earlier could be prudent as well. Doing it right after the intel-gtt probe seems appropriate. Also tested this on 946gz,elk,ilk and all seemed quite happy with this change. v2: Reorder init_hw vs. enable_hw functions (Chris) Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: drm-intel-fixes@lists.freedesktop.org Fixes: ebb7c78d358b ("agp/intel-gtt: Only register fake agp driver for gen1") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1462559755-353-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-05-10drm/exynos: Use lockless gem BO free callbackDaniel Vetter
No dev->struct_mutex anywhere to be seen. Cc: Inki Dae <inki.dae@samsung.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Acked-by: Inki Dae <inki.dae@samsung.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1461691808-12414-18-git-send-email-daniel.vetter@ffwll.ch
2016-05-10drm: Make drm_encoder_helper_funcs optionalNoralf Trønnes
Make drm_encoder_helper_funcs and it's functions optional to avoid having dummy functions. Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1462454674-2246-3-git-send-email-noralf@tronnes.org
2016-05-10x86: Silence 32bit compiler warning in intel_graphics_stolen()Chris Wilson
arch/x86/kernel/early-quirks.c: In function ‘intel_graphics_stolen’: arch/x86/kernel/early-quirks.c:539:9: warning: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 2 has type ‘phys_addr_t’ [-Wformat=] "0x%llx-0x%llx\n", base, base + size - 1); ^ arch/x86/kernel/early-quirks.c:539:9: warning: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘phys_addr_t’ [-Wformat=] v2: Use %pa for addresses Fixes: ee0629cfd3c16 (drm/i915: Function per early graphics quirk) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> #v1 Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1462811982-1567-1-git-send-email-chris@chris-wilson.co.uk
2016-05-10Merge branch 'drm-etnaviv-next' of git://git.pengutronix.de:/git/lst/linux ↵Dave Airlie
into drm-next not much new stuff this time. A (micro-)optimization to allow the hangcheck timer to be coalesced with other wakeups in the system and a fix to handle mmaping of prime imported and userptr buffers correctly. I don't think we have seen any actual issues going back to this yet, so I figured it's safer to get this in via drm-next rather than smashing it into fixes. * 'drm-etnaviv-next' of git://git.pengutronix.de:/git/lst/linux: drm/etnaviv: fix mmap operations for userptr and dma-buf objects drm/etnaviv: take etnaviv_gem_obj in etnaviv_gem_mmap_obj drm/etnaviv: use deferrable timer for hangcheck handler timer: add setup_deferrable_timer macro
2016-05-10Merge tag 'mediatek-drm-2016-05-09' of ↵Dave Airlie
git://git.pengutronix.de/git/pza/linux into drm-next MT8173 DRM support - device tree binding documentation for all MT8173 display subsystem components - basic mediatek-drm driver for MT8173 with two optional, currently fixed output paths: - DSI encoder support for DSI and (via bridge) eDP panels - DPI encoder support for output to HDMI bridge - necessary clock tree changes for the DPI->HDMI path - export mtk-smi functions used by mediatek-drm * tag 'mediatek-drm-2016-05-09' of git://git.pengutronix.de/git/pza/linux: clk: mediatek: remove hdmitx_dig_cts from TOP clocks clk: mediatek: Add hdmi_ref HDMI PHY PLL reference clock output clk: mediatek: make dpi0_sel propagate rate changes drm/mediatek: Add DPI sub driver drm/mediatek: Add DSI sub driver drm/mediatek: Add DRM Driver for Mediatek SoC MT8173. dt-bindings: drm/mediatek: Add Mediatek display subsystem dts binding memory: mtk-smi: export mtk_smi_larb_get/put
2016-05-09drm/i915: Add a FIXME about crtc !active vs. watermarksVille Syrjälä
When the crtc is enabled but !active, we should still compute the watermarks as if the planes were visible. That would make it more likely that the we can later transition to active without errors. Add a FIXME to remind people that we're doing the wrong thing now. We should perhaps just move the wm computation for each individual plane into the .check_plane hook, and later we'd just combine the results from all active planes. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1461940278-17122-2-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2016-05-09drm/i915: Calculate IPS linetime watermark based on future cdclkVille Syrjälä
Use the cdclk we're going to be using when the pipe gets enabled to compute the IPS linetime watermark. The current cdclk frequency is irrelevant at this point since it can still change. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1461940278-17122-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2016-05-09drm/i915: Store a i915 backpointer from engine, and use itChris Wilson
text data bss dec hex filename 6309351 3578714 696320 10584385 a18141 vmlinux 6308391 3578714 696320 10583425 a17d81 vmlinux Almost 1KiB of code reduction. v2: More s/INTEL_INFO()->gen/INTEL_GEN()/ and IS_GENx() conversions text data bss dec hex filename 6304579 3578778 696320 10579677 a16edd vmlinux 6303427 3578778 696320 10578525 a16a5d vmlinux Now over 1KiB! Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1462545621-30125-3-git-send-email-chris@chris-wilson.co.uk
2016-05-09drm/i915/execlists: Refactor common engine setupChris Wilson
Move all of the constant assignments up front and into a common function. This is primarily to ensure the backpointers are set as early as possible for later use during initialisation. v2: Use a constant struct so that all the similar values are set together. v3: Sanitize the engine's IMR to disable any potential interrupt before we are ready (enabled in init_hw). v4: Ignore the engine's IMR, to be resolved later Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Dave Gordon <david.s.gordon@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1462545621-30125-2-git-send-email-chris@chris-wilson.co.uk
2016-05-09drm/i915: Small display interrupt handlers tidyTvrtko Ursulin
I have noticed some of our interrupt handlers use both dev and dev_priv while they could get away with only dev_priv in the huge majority of cases. Tidying that up had a cascading effect on changing functions prototypes, so relatively big churn factor, but I think it is for the better. For example even where changes cascade out of i915_irq.c, for functions prefixed with intel_, genX_ or <plat>_, it makes more sense to take dev_priv directly anyway. This allows us to eliminate local variables and intermixed usage of dev and dev_priv where only one is good enough. End result is shrinkage of both source and the resulting binary. i915.ko: - .text 000b0899 + .text 000b0619 Or if we look at the Gen8 display irq chain: -00000000000006ad t gen8_irq_handler +0000000000000663 t gen8_irq_handler -0000000000000028 T intel_opregion_asle_intr +0000000000000024 T intel_opregion_asle_intr -000000000000008c t ilk_hpd_irq_handler +000000000000007f t ilk_hpd_irq_handler -0000000000000116 T intel_check_page_flip +0000000000000112 T intel_check_page_flip -000000000000011a T intel_prepare_page_flip +0000000000000119 T intel_prepare_page_flip -0000000000000014 T intel_finish_page_flip_plane +0000000000000013 T intel_finish_page_flip_plane -0000000000000053 t hsw_pipe_crc_irq_handler +000000000000004c t hsw_pipe_crc_irq_handler -000000000000022e t cpt_irq_handler +0000000000000213 t cpt_irq_handler So small shrinkage but it is all fast paths so doesn't harm. Situation is similar in other interrupt handlers as well. v2: Tidy intel_queue_rps_boost_for_request as well. (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>
2016-05-09drm/i915: Determine DP++ type 1 DVI adaptor presence based on VBTVille Syrjälä
DP dual mode type 1 DVI adaptors aren't required to implement any registers, so it's a bit hard to detect them. The best way would be to check the state of the CONFIG1 pin, but we have no way to do that. So as a last resort, check the VBT to see if the HDMI port is in fact a dual mode capable DP port. v2: Deal with VBT code reorganization Deal with DRM_DP_DUAL_MODE_UNKNOWN Reduce DEVICE_TYPE_DP_DUAL_MODE_BITS a bit Accept both DP and HDMI dvo_port in VBT as my BSW at least declare its DP port as HDMI :( v3: Ignore DEVICE_TYPE_NOT_HDMI_OUTPUT (Shashank) Cc: stable@vger.kernel.org Cc: Tore Anderson <tore@fud.no> Reported-by: Tore Anderson <tore@fud.no> Fixes: 7a0baa623446 ("Revert "drm/i915: Disable 12bpc hdmi for now"") Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1462362322-31278-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
2016-05-09drm/i915: Enable/disable TMDS output buffers in DP++ adaptor as neededVille Syrjälä
To save a bit of power, let's try to turn off the TMDS output buffers in DP++ adaptors when we're not driving the port. v2: Let's not forget DDI, toss in a debug message while at it v3: Just do the TMDS output control based on adaptor type. With the helper getting passed the type, we wouldn't actually have to check at all in the driver, but the check eliminates the debug output more honest Cc: stable@vger.kernel.org Cc: Tore Anderson <tore@fud.no> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1462216105-20881-4-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
2016-05-09drm/i915: Respect DP++ adaptor TMDS clock limitVille Syrjälä
Try to detect the max TMDS clock limit for the DP++ adaptor (if any) and take it into account when checking the port clock. Note that as with the sink (HDMI vs. DVI) TMDS clock limit we'll ignore the adaptor TMDS clock limit in the modeset path, in case users are already "overclocking" their TMDS links. One subtle change here is that we'll have to respect the adaptor TMDS clock limit when we decide whether to do 12bpc or 8bpc, otherwise we might end up picking 12bpc and accidentally driving the TMDS link out of spec even when the user chose a mode that fits wihting the limits at 8bpc. This means you can't "overclock" your DP++ dongle at 12bpc anymore, but you can continue to do so at 8bpc. Note that for simplicity we'll use the I2C access method for all dual mode adaptors including type 2. Otherwise we'd have to start mixing DP AUX and HDMI together. In the future we may need to do that if we come across any board designs that don't hook up the DDC pins to the DP++ connectors. Such boards would obviously only work with type 2 dual mode adaptors, and not type 1. v2: Store adaptor type under indel_hdmi->dp_dual_mode Deal with DRM_DP_DUAL_MODE_UNKNOWN Pass adaptor type to drm_dp_dual_mode_max_tmds_clock(), and use it for type1 adaptors as well Cc: stable@vger.kernel.org Reported-by: Tore Anderson <tore@fud.no> Fixes: 7a0baa623446 ("Revert "drm/i915: Disable 12bpc hdmi for now"") Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1462216105-20881-3-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
2016-05-09drm: Add helper for DP++ adaptorsVille Syrjälä
Add a helper which aids in the identification of DP dual mode (aka. DP++) adaptors. There are several types of adaptors specified: type 1 DVI, type 1 HDMI, type 2 DVI, type 2 HDMI Type 1 adaptors have a max TMDS clock limit of 165MHz, type 2 adaptors may go as high as 300MHz and they provide a register informing the source device what the actual limit is. Supposedly also type 1 adaptors may optionally implement this register. This TMDS clock limit is the main reason why we need to identify these adaptors. Type 1 adaptors provide access to their internal registers and the sink DDC bus through I2C. Type 2 adaptors provide this access both via I2C and I2C-over-AUX. A type 2 source device may choose to implement either of these methods. If a source device implements the I2C-over-AUX method, then the driver will obviously need specific support for such adaptors since the port is driven like an HDMI port, but DDC communication happes over the AUX channel. This helper should be enough to identify the adaptor type (some type 1 DVI adaptors may be a slight exception) and the maximum TMDS clock limit. Another feature that may be available is control over the TMDS output buffers on the adaptor, possibly allowing for some power saving when the TMDS link is down. Other user controllable features that may be available in the adaptors are downstream i2c bus speed control when using i2c-over-aux, and some control over the CEC pin. I chose not to provide any helper functions for those since I have no use for them in i915 at this time. The rest of the registers in the adaptor are mostly just information, eg. IEEE OUI, hardware and firmware revision, etc. v2: Pass adaptor type to helper functions to ease driver implementation Fix a bunch of typoes (Paulo) Add DRM_DP_DUAL_MODE_UNKNOWN for the case where we don't (yet) know the type (Paulo) Reject 0x00 and 0xff DP_DUAL_MODE_MAX_TMDS_CLOCK values (Paulo) Adjust drm_dp_dual_mode_detect() type2 vs. type1 detection to ease future LSPCON enabling Remove the unused DP_DUAL_MODE_LAST_RESERVED define v3: Fix kernel doc function argument descriptions (Jani) s/NONE/UNKNOWN/ in drm_dp_dual_mode_detect() docs Add kernel doc for enum drm_dp_dual_mode_type Actually build the docs Fix more typoes v4: Adjust code indentation of type2 adaptor detection (Shashank) Add debug messages for failurs cases (Shashank) v5: EXPORT_SYMBOL(drm_dp_dual_mode_read) (Paulo) Cc: stable@vger.kernel.org Cc: Tore Anderson <tore@fud.no> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> (v4) Link: http://patchwork.freedesktop.org/patch/msgid/1462542412-25533-1-git-send-email-ville.syrjala@linux.intel.com
2016-05-09drm/i915: Dump pipe config when intel_modeset_pipe_config fails.Maarten Lankhorst
This makes it easier to debug issues like https://bugs.freedesktop.org/show_bug.cgi?id=93477 Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Chris Wilson <|chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/843f4327-1574-cf8e-0776-adbb0d58c2c0@mblankhorst.nl Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2016-05-09Revert "mfd: intel_soc_pmic_core: Terminate panel control GPIO lookup table ↵Daniel Vetter
correctly" This reverts commit 3543995a71b9150621bf30f4b45820d9cf65adb4. I mixed up maintainers and thought Linus' ack was for the mfd tree. But Lee Jones (the real maintainer) wants to merge this through the mfd tree, so revert here. Cc: Lee Jones <lee.jones@linaro.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2016-05-09drm/i915: Allow MI_LOAD_REGISTER_REG between whitelisted registers.Kenneth Graunke
Allowing register copies where the source and destination are both whitelisted should be safe, and is useful. For example, Mesa uses this to load the command streamer math registers with data from the pipeline statistics counters. v2: Reject writes to OACONTROL (and reads as well :( Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> # v1 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1462521014-13595-1-git-send-email-chris@chris-wilson.co.uk
2016-05-09Merge tag 'v4.6-rc7' into drm-nextDave Airlie
Merge this back as we've built up a fair few conflicts, and I have some newer trees to pull in.
2016-05-09drm/amdgpu: fix build on aarch64.Dave Airlie
Same fix went in previously for some other files. Signed-off-by: Dave Airlie <airlied@redhat.com>
2016-05-09Merge branch 'msm-next' of git://people.freedesktop.org/~robclark/linux into ↵Dave Airlie
drm-next Mostly cleanups, fixes, and 'struct fence' conversion this time around, with one reservation patch which is a-b Sumit (which the fence conversion patches depend on). * 'msm-next' of git://people.freedesktop.org/~robclark/linux: (25 commits) drm/msm: Drop load/unload drm_driver ops drm/msm: Centralize connector registration/unregistration drm/msm/hdmi: Prevent gpio_free related kernel warnings drm/msm: print offender task name on hangcheck recovery drm/msm: fix leak in failed submit path drm/msm: de-indent submit_create() drm/msm: drop return from gpu->submit() drm/msm/mdp4: Don't manage DSI PLL regulators in MDP driver drm/msm/edp: Drop regulator_set_voltage call drm/msm/dsi: Fix regulator API abuse drm/msm: Move call to PTR_ERR_OR_ZERO after reassignment drm/msm/mdp: Add support for more RGBX formats drm: msm: remove unused variable drm/msm: fix ->last_fence() after recover drm/msm: 'struct fence' conversion drm/msm: remove fence_cbs drm/msm: introduce msm_fence_context drm/msm: split locking and pinning BO's drm/msm/gpu: simplify tracking in-flight bo's drm/msm: split out timeout_to_jiffies helper ...
2016-05-09Merge tag 'topic/drm-misc-2016-05-08' of ↵Dave Airlie
git://anongit.freedesktop.org/drm-intel into drm-next Refcounting is hard, so here's a quick pull request with the one-liner to fix up i915. Otherwise just a few other small things I picked up. Plus the regression fix from Marten for rmfb behaviour that lingered around forever since no testers. Feel free to cherry-pick that over to drm-fixes, but given that there's not many who seemed to have cared, meh. * tag 'topic/drm-misc-2016-05-08' of git://anongit.freedesktop.org/drm-intel: drm/i915: Correctly refcount connectors in hw state readou drm/panel: Flesh out kerneldoc drm: Add gpu.tmpl docbook to MAINTAINERS entry drm/core: Do not preserve framebuffer on rmfb, v4. drm: Fix up markup fumble drm/fb_helper: Fix a few typos
2016-05-08Linux 4.6-rc7v4.6-rc7Linus Torvalds
2016-05-08drm/i915: Update DRIVER_DATE to 20160508Daniel Vetter
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2016-05-08drm/msm: Drop load/unload drm_driver opsArchit Taneja
The load/unload drm_driver ops are deprecated. They should be removed as they result in creation of devices visible to userspace even before the drm_device is registered. Drop these ops and use drm_dev_alloc/register and drm_dev_unregister/unref to explicitly create and destroy the drm device in the msm platform driver's bind and unbind ops. With this in use, the drm connectors are only registered once the drm_device is registered. It also fixes the issue of stray debugfs files after the msm module is removed. With this, all the debugfs files are removed, and allows successive module insertions/removals. Signed-off-by: Archit Taneja <architt@codeaurora.org>
2016-05-08drm/msm: Centralize connector registration/unregistrationArchit Taneja
Move the drm_connector registration from the encoder(HDMI/DSI etc) drivers to the msm platform driver. This will simplify the task of ensuring that the connectors are registered only after the drm_device itself is registered. The connectors' destroy ops are made to use kzalloc instead of devm_kzalloc to ensure that that the connectors can be successfully unregistered when the msm driver module is removed. The memory for the connectors is unallocated when drm_mode_config_cleanup() is called during either during an error or during driver remove. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2016-05-08drm/msm/hdmi: Prevent gpio_free related kernel warningsArchit Taneja
Calling the legacy gpio_free on an invalid GPIO (a GPIO numbered -1) results in kernel warnings. This causes a lot of backtraces when we try to unload the drm/msm module. Call gpio_free only on valid GPIOs. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2016-05-08drm/msm: print offender task name on hangcheck recoveryRob Clark
Track the pid per submit, so we can print the name of the task which submitted the batch that caused the gpu to hang. Signed-off-by: Rob Clark <robdclark@gmail.com>
2016-05-08drm/msm: fix leak in failed submit pathRob Clark
Signed-off-by: Rob Clark <robdclark@gmail.com>
2016-05-08drm/msm: de-indent submit_create()Rob Clark
Signed-off-by: Rob Clark <robdclark@gmail.com>
2016-05-08drm/msm: drop return from gpu->submit()Rob Clark
At this point, there is nothing left to fail. And submit already has a fence assigned and is added to the submit_list. Any problems from here on out are asynchronous (ie. hangcheck/recovery). Signed-off-by: Rob Clark <robdclark@gmail.com>
2016-05-08drm/msm/mdp4: Don't manage DSI PLL regulators in MDP driverArchit Taneja
The MDP4 driver tries to request and set voltages for regulators required by the DSI PLLs. Firstly, the MDP4 driver shouldn't manage the DSI regulators, this should be handled in the DSI driver. Secondly, it shouldn't try to set a fixed voltage for regulators. Voltage constraints should be specified on the regulator via DT and managed by the regulator core. Remove all the DSI PLL regulator related code from the MDP4 driver. It's managed in the DSI driver for MSM8960/APQ8064 already. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2016-05-08drm/msm/edp: Drop regulator_set_voltage callArchit Taneja
The eDP driver tries to set a fixed voltage for one of its regulators(vdda) before enabling it. This shouldn't be done by the driver, the voltage constraints should be specified on the regulator via DT and managed by the regulator core. A driver should call regulator_set_voltage only if it needs to change the voltage during runtime. Drop the regulator_set_voltage call. Mention in a comment the voltage that the regulator expects. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2016-05-08drm/msm/dsi: Fix regulator API abuseArchit Taneja
The voltage changing code in this driver is broken and should be removed. The driver sets a single, exact voltage on probe. Unless there is a very good reason for this (which should be documented in comments) constraints like this need to be set via the machine constraints, voltage setting in a driver is expected to be used in cases where the voltage varies at runtime. In addition client drivers should almost never be calling regulator_can_set_voltage(), if the device needs to set a voltage it needs to set the voltage and the regulator core will handle the case where the regulator is fixed voltage. If the driver simply skips setting the voltage if it doesn't have permission then it should just not bother in the first place. Originally authored by Mark Brown <broonie@kernel.org> Remove the min/max voltage data entries per SoC managed by the driver. These aren't needed as we don't try to set voltages any more. Mention in comments the voltages that each regulator expects. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
generated by cgit (git 2.34.1) at 2025-09-11 23:29:58 +0000