aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu/drm
AgeCommit message (Collapse)AuthorFilesLines
2017-01-06drm/sti: sti_vtg: Handle return NULL error from devm_ioremap_nocacheArvind Yadav1-0/+4
Here, If devm_ioremap_nocache will fail. It will return NULL. Kernel can run into a NULL-pointer dereference. This error check will avoid NULL pointer dereference. Signed-off-by: Arvind Yadav <[email protected]> Acked-by: Vincent Abriou <[email protected]>
2017-01-06drm/sti: remove deprecated sti_vtac.c fileVincent Abriou4-226/+0
stih416 chip family is no more supported in Linux v4.9. It is then useless to keep sti_vtac.c file since it not used at all for the stih407/10 chip family supported by sti driver. Signed-off-by: Vincent Abriou <[email protected]>
2017-01-06drm/sti: create fbdev at bindingVincent Abriou1-13/+14
Do not wait for a hot plug event to create fbdev. Cc: Tomi Valkeinen <[email protected]> Signed-off-by: Vincent Abriou <[email protected]>
2017-01-06drm/sti: update fps debugfs entriesVincent Abriou2-5/+14
This update allows to have a clearer fps log trace by adding information about plane size and plane pixel format. Signed-off-by: Vincent Abriou <[email protected]>
2017-01-06drm/sti: do not post HQVDP command if no updateFabien DESSENNE1-0/+15
Do not process update requests with unmodified parameters. Since the HQVDP command queue is limited to 2, we shall take care of not posting unneeded commands, which would abusively fill the command queue leading to frame update skip. This typically happens when the driver is called with legacy (non-atomic) IOCTL : in that case atomic_update() is called multiple times with the same parameters. Signed-off-by: Fabien Dessenne <[email protected]> Acked-by: Benjamin Gaignard <[email protected]>
2017-01-06drm/sti: load XP70 firmware only onceFabien DESSENNE1-2/+6
When a plane is enabled, after having been disabled, do not reload XP70 firmware again, but only register VTG again Signed-off-by: Fabien Dessenne <[email protected]> Acked-by: Benjamin Gaignard <[email protected]>
2017-01-06drm/sti: allow audio playback on HDMI even if disabled.Arnaud Pouliquen1-104/+101
This fix allows to play audio while HDMI is disconnected. When HDMI is disable, audio configuration is stored and samples are dropped (by HDMI IP). When HDMI is enabled, audio HDMI configuration is applied and samples are outputted on HDMI wire. Signed-off-by: Arnaud Pouliquen <[email protected]> Acked-by: Vincent Abriou <[email protected]>
2017-01-06drm: allow to use mmuless SoCBenjamin Gaignard2-2/+73
Some SoC without MMU have display driver where a drm/kms driver could be implemented. Before doing such kind of thing drm/kms must allow to use mmuless devices. This patch propose to remove MMU configuration flag and add a cma helper function to help implementing mmuless display driver version 4: - add documentation about drm_gem_cma_get_unmapped_area() - stub it MMU case Signed-off-by: Benjamin Gaignard <[email protected]> [danvet: Use recommended struct member references in kernel-doc.] Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-01-06drm: compile drm_vm.c only when neededBenjamin Gaignard4-1/+15
drm_vm.c functions are only need for DRM_LEGACY and DRM_NOUVEAU. Use a new DRM_VM to define when drm_vm.c in needed. stub drm_legacy_vma_flush() to avoid compilation issues version 4: - a "config DRM_VM" in Kconfig Signed-off-by: Benjamin Gaignard <[email protected]> [danvet: Fix conflict.] Signed-off-by: Daniel Vetter <[email protected]>
2017-01-05drm/i915: Only skip requests once a context is bannedChris Wilson1-7/+12
If we skip before banning, we have an inconsistent interface between execbuf still queueing valid request but those requests already queued being cancelled. If we only cancel the pending requests once we stop accepting new requests, the user interface is more consistent. Reported-by: Tvrtko Ursulin <[email protected]> Fixes: 821ed7df6e2a ("drm/i915: Update reset path to fix incomplete requests") Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Mika Kuoppala <[email protected]> Cc: <[email protected]> # v4.9+ Reviewed-by: Tvrtko Ursulin <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-01-05drm/i915: Move a few more utility macros to i915_utils.hChris Wilson2-20/+20
Now that we have split out a header file for simple macros (that maybe we can promote into a core header), move a few macros across from i915_drv.h Signed-off-by: Chris Wilson <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Matthew Auld <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]>
2017-01-05drm/i915: Clear ret before unbinding in i915_gem_evict_something()Chris Wilson1-0/+1
Missed when rebasing patches, I failed to set ret to zero before starting the unbind loop (which depends upon ret being zero). Reported-by: Matthew Auld <[email protected]> Fixes: 9332f3b1b99a ("drm/i915: Combine loops within i915_gem_evict_something") Signed-off-by: Chris Wilson <[email protected]> Cc: Matthew Auld <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Matthew Auld <[email protected]> Cc: <[email protected]> # v4.9+
2017-01-05drm/i915/guc: Exclude the upper end of the Global GTT for the GuCChris Wilson3-0/+14
The GuC uses a special mapping for the upper end of the Global GTT, similar to the way it uses a special mapping for the lower end, so exclude it from our drm_mm to prevent us using it. v2: Rename to reflect that it is unmappable similar to the region at the bottom of the GGTT, and couple it into the assertion that we don't feed unmappable addresses to the GuC. Signed-off-by: Chris Wilson <[email protected]> Cc: Michal Wajdeczko <[email protected]> Cc: Arkadiusz Hiler <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Reviewed-by: Arkadiusz Hiler <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-01-05drm/i915: Move a few utility macros into a separate headerChris Wilson3-16/+45
In order to defeat some circular dependencies between headers to allow use of e.g. range_overflows() in a header, move the simple independent macros into their own header. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-01-05drm/i915/execlists: Reorder execlists register enablingChris Wilson1-14/+4
Empirically we restart following a GPU reset more successfully if we call lrc_init_hws() (which contains a posting read) last. (The failure mode that was observed was that breadcrumb writes into the HWS from the recovered requests went astray leading to the context-switch maintaining forward progress, but the requests not being retired/completed.) For clarity, lrc_init_hws() is inlined (and the unused function then removed). Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Mika Kuoppala <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-01-05drm/i915: Assert that we do create the deferred contextChris Wilson1-0/+1
In order to convince static analyzers that the allocation function returns an error or sets ce->state, assert that it is set afterwards. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-01-05drm/i915: Assert all timeline requests are gone before finiChris Wilson1-4/+12
During i915_gem_timeline_fini(), assert that all the timeline's request are completed and removed from the timeline. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-01-05drm: crc: Wait for a frame before returning from open()Tomeu Vizoso1-6/+17
Don't return from the open() call on the crc/data file until the HW has produced a first frame, as there's great variability in when the HW is able to do that and userspace shouldn't have to guess when this specific HW is ready to start giving frame CRCs. Signed-off-by: Tomeu Vizoso <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-01-05drm: Move locking into drm_debugfs_crtc_crc_addTomeu Vizoso1-2/+7
There's no reason any more for callers of this function to take the lock themselves, so just move the lock to the function to avoid confusion and bugs when more callers are contributed. Signed-off-by: Tomeu Vizoso <[email protected]> Reviewed-by: Emil Velikov <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-01-05drm/imx: imx-tve: Remove unused variableFabio Estevam1-8/+3
'ret' is never used in tve_enable/tve_disable(), so just remove it. Signed-off-by: Fabio Estevam <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-01-05Revert "drm: nouveau: fix build when LEDS_CLASS=m"Daniel Vetter1-1/+0
This reverts commit a5ad0fd8524e5144512a5c25eda5a5d6fd55fda8. It results in kconfing complaining about recursive depencies: drivers/usb/Kconfig:39:error: recursive dependency detected! For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/input/mouse/Kconfig:187: symbol MOUSE_APPLETOUCH depends on INPUT For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/input/Kconfig:8: symbol INPUT is selected by VT For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/tty/Kconfig:12: symbol VT is selected by FB_STI For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/video/fbdev/Kconfig:678: symbol FB_STI depends on FB For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/gpu/drm/Kconfig:72: symbol DRM_KMS_FB_HELPER is selected by DRM_KMS_CMA_HELPER For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/gpu/drm/Kconfig:128: symbol DRM_KMS_CMA_HELPER is selected by DRM_HDLCD For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/gpu/drm/arm/Kconfig:6: symbol DRM_HDLCD depends on COMMON_CLK For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/clk/Kconfig:9: symbol COMMON_CLK is selected by X86_INTEL_QUARK For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" arch/x86/Kconfig:554: symbol X86_INTEL_QUARK depends on X86_PLATFORM_DEVICES For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/platform/x86/Kconfig:5: symbol X86_PLATFORM_DEVICES is selected by DRM_NOUVEAU For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/gpu/drm/nouveau/Kconfig:1: symbol DRM_NOUVEAU depends on LEDS_CLASS For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/leds/Kconfig:16: symbol LEDS_CLASS is selected by ATH9K_HTC For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/net/wireless/ath/ath9k/Kconfig:158: symbol ATH9K_HTC depends on USB warning: (DRM_NOUVEAU && DRM_I915 && DRM_GMA500) selects ACPI_VIDEO which has unmet direct dependencies (ACPI && X86 && +BACKLIGHT_CLASS_DEVICE && INPUT) And there's apparently a better patch available already. Signed-off-by: Daniel Vetter <[email protected]>
2017-01-05drm: Add kernel-doc for drm_crtc_commit_get/putDaniel Vetter1-7/+2
I was lazy, rectify that! Also align with drm_atomic_state_get/put for ocd. v2: Git add helps. Acked-by: Alex Deucher <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-01-04drm/i915: Revoke fenced GTT mmapings across GPU resetChris Wilson4-3/+35
The fence registers are clobbered by a GPU reset. If there is concurrent user access to a fenced region via a GTT mmaping, the access will not be fenced during the reset (until we restore the fences afterwards). In order to prevent invalid access during the reset, before we clobber the fences first we must invalidate the GTT mmapings. Access to the mmap will then be forced to fault in the page, and in handling the fault, i915_gem_fault() will take the struct_mutex and wait upon the reset to complete. v2: Fix up commentary. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99274 Testcase: igt/gem_mmap_gtt/hang Signed-off-by: Chris Wilson <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Tvrtko Ursulin <[email protected]>
2017-01-04drm/i915: enable FBC on gen9+ tooPaulo Zanoni1-1/+1
Gen9+ platforms have been seeing a lot of screen flickerings and underruns, so I never felt comfortable in enabling FBC on these platforms since I didn't want to throw yet another feature on top of the already complex problem. We now have code that automatically disables FBC if we ever get an underrun, and the screen flickerings seem to be mostly gone, so it may be a good time to try to finally enable FBC by default on the newer platforms. Besides, BDW FBC has been working fine over the year, which gives me a little more confidence now. For a little more information, please refer to commit a98ee79317b4 ("drm/i915/fbc: enable FBC by default on HSW and BDW"). v2: Enable not only on SKL, but for everything new (Daniel). v3: Rebase after the intel_sanitize_fbc_option() change. v4: New rebase after 8 months, drop expired R-B tags. Signed-off-by: Paulo Zanoni <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-01-04drm/i915: actually drive the BDW reserved IDsPaulo Zanoni1-0/+1
Back in 2014, commit fb7023e0e248 ("drm/i915: BDW: Adding Reserved PCI IDs.") added the reserved PCI IDs in order to try to make sure we had working drivers in case we ever released products using these IDs (since we had instances of this type of problem in the past). The problem is that the patch only touched the macros used by early-quirks.c and by the user space components that rely on i915_pciids.h, it didn't touch the macros used by i915_pci.c. So we correctly handled the stolen memory for these theoretical IDs, but we didn't actually drive the devices from i915.ko. So this patch fixes the original commit by actually making i915.ko drive these IDs, which was the goal. There's no information on what would be the GT count on these IDs, so we just go with the safer intel_broadwell_info, at the risk of ignoring a possibly inexistent BSD2_RING. I did some checking, and it seems that these IDs are driven by intel-gpu-tools, xf86-video-intel and libdrm (since they contain old copies of i915_pciids.h), but they are not checked by mesa. The alternative to this patch would be to just assume we're actually never going to use these IDs, and then remove them from our ID lists and make sure our user space components sync the latest i915_pciids.h copy. I'm fine with either approaches, as long as we make sure that every component tries to drive the same list of PCI IDs. Fixes: fb7023e0e248 ("drm/i915: BDW: Adding Reserved PCI IDs.") Cc: Rodrigo Vivi <[email protected]> Cc: Ben Widawsky <[email protected]> Cc: Jani Nikula <[email protected]> Signed-off-by: Paulo Zanoni <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-01-04drm/atomic: Fix outdated comment.Maarten Lankhorst1-8/+4
Commit 0853695c3ba4 ("drm: Add reference counting to drm_atomic_state") adds reference counting to atomic state, but didn't update the comments in drm_atomic_(nonblocking_)commit. Clarify lifetime a bit more. Fixes: 0853695c3ba4 ("drm: Add reference counting to drm_atomic_state") Cc: <[email protected]> # v4.10-rc1+ Cc: Chris Wilson <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Maarten Lankhorst <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-01-04drm/omap: panel-sony-acx565akm.c: Add MODULE_ALIASJarkko Nikula1-0/+1
Add module alias for Sony ACX565AKM LCD panel. This makes it probe on Nokia N900 when panel driver is built as a module. Signed-off-by: Jarkko Nikula <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]>
2017-01-04drm/omap: dsi: fix compile errors when enabling debug printsH. Nikolaus Schaller1-9/+9
dsi.c compile fails if PRINT_VERBOSE_VM_TIMINGS is enabled, as the video timings were not converted in the code behind that ifdef. Note that PRINT_VERBOSE_VM_TIMINGS has to be enabled by hand, there's no config option for it. Signed-off-by: H. Nikolaus Schaller <[email protected]> Acked-by: Peter Ujfalusi <[email protected]> [[email protected]: fixed the patch description] Signed-off-by: Tomi Valkeinen <[email protected]>
2017-01-04drm/meson: Fix CVBS VDAC disableNeil Armstrong1-1/+1
This commit fixes the VDAC disabling register write values. Fixes: bbbe775ec5b5 ("drm: Add support for Amlogic Meson Graphic Controller") Signed-off-by: Neil Armstrong <[email protected]>
2017-01-04drm/meson: Fix CVBS initialization when HDMI is configured by bootloaderNeil Armstrong1-0/+19
When the HDMI output is configured by the bootloader, there is mismatch is the pipeline configuration and the Vsync interrupt fails to trigger. This commit disables the HDMI blocks in the probe phase. Fixes: bbbe775ec5b5 ("drm: Add support for Amlogic Meson Graphic Controller") Signed-off-by: Neil Armstrong <[email protected]>
2017-01-04Merge tag 'drm-misc-next-2016-12-30' of ↵Daniel Vetter194-1338/+3942
git://anongit.freedesktop.org/git/drm-misc into drm-intel-next-queued Directly merge drm-misc into drm-intel since Dave is on vacation and we need the various drm-misc patches (fb format rework, drm mm fixes, selftest framework and others). Also pulled back -rc2 in first to resync with drm-intel-fixes and make sure I can reuse the exact rerere solutions from drm-tip for safety, and because I'm lazy. Signed-off-by: Daniel Vetter <[email protected]>
2017-01-04Merge tag 'v4.10-rc2' into drm-intel-next-queuedDaniel Vetter266-3235/+65094
Backmerge Linux 4.10-rc2 to resync with our -fixes cherry-picks. I've done the backmerge directly because Dave is on vacation. Signed-off-by: Daniel Vetter <[email protected]>
2017-01-04drm: Clean up planes in atomic commit helper failure pathLaurent Pinchart1-1/+3
If waiting for fences fails for blocking commits, planes must be cleaned up before returning. Cc: [email protected] Fixes: f6ce410a59a4 ("drm/fence: allow fence waiting to be interrupted by userspace") Signed-off-by: Laurent Pinchart <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-01-04drm: reference count event->completionDaniel Vetter2-1/+12
When writing the generic nonblocking commit code I assumed that through clever lifetime management I can assure that the completion (stored in drm_crtc_commit) only gets freed after it is completed. And that worked. I also wanted to make nonblocking helpers resilient against driver bugs, by having timeouts everywhere. And that worked too. Unfortunately taking boths things together results in oopses :( Well, at least sometimes: What seems to happen is that the drm event hangs around forever stuck in limbo land. The nonblocking helpers eventually time out, move on and release it. Now the bug I tested all this against is drivers that just entirely fail to deliver the vblank events like they should, and in those cases the event is simply leaked. But what seems to happen, at least sometimes, on i915 is that the event is set up correctly, but somohow the vblank fails to fire in time. Which means the event isn't leaked, it's still there waiting for eventually a vblank to fire. That tends to happen when re-enabling the pipe, and then the trap springs and the kernel oopses. The correct fix here is simply to refcount the crtc commit to make sure that the event sticks around even for drivers which only sometimes fail to deliver vblanks for some arbitrary reasons. Since crtc commits are already refcounted that's easy to do. References: https://bugs.freedesktop.org/show_bug.cgi?id=96781 Cc: Jim Rees <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Jani Nikula <[email protected]> Reviewed-by: Maarten Lankhorst <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-01-04drm/i915: Update comment that sets I915_MODE_FLAG_INHERITEDDaniel Vetter1-11/+3
The code was moved, but the comment not updated. It confused me. Fixes: 7f4c62840cc4 ("drm/i915: Assign hwmode after encoder state readout") Cc: Maarten Lankhorst <[email protected]> Cc: Patrik Jakobsson <[email protected]> Cc: Ville Syrjälä <[email protected]> Reviewed-by: Maarten Lankhorst <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-01-04gpu: drm: mgag200: mgag200_main:- Handle error from pci_iomapArvind Yadav1-0/+2
Here, pci_iomap can fail, handle this case and return -ENOMEM. Signed-off-by: Arvind Yadav <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-01-04drm: nouveau: fix build when LEDS_CLASS=mRandy Dunlap1-0/+1
Fix build errors in nouveau driver when CONFIG_LEDS_CLASS=m and CONFIG_DRM_NOUVEAU=y. If LEDS_CLASS is enabled, DRM_NOUVEAU is restricted to the same kconfig value as LEDS_CLASS. drivers/built-in.o: In function `nouveau_do_suspend': nouveau_drm.c:(.text+0x2030b1): undefined reference to `nouveau_led_suspend' drivers/built-in.o: In function `nouveau_do_resume': nouveau_drm.c:(.text+0x2034ca): undefined reference to `nouveau_led_resume' drivers/built-in.o: In function `nouveau_drm_unload': nouveau_drm.c:(.text+0x203a15): undefined reference to `nouveau_led_fini' drivers/built-in.o: In function `nouveau_drm_load': nouveau_drm.c:(.text+0x204423): undefined reference to `nouveau_led_init' BTW, this line in Kbuild: nouveau-$(CONFIG_LEDS_CLASS) += nouveau_led.o does nothing when CONFIG_LEDS_CLASS=m and CONFIG_DRM_NOUVEAU=y. Signed-off-by: Randy Dunlap <[email protected]> Reported-by: kbuild test robot <[email protected]> Cc: Martin Peres <[email protected]> Cc: Ben Skeggs <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-01-04drm: tilcdc: simplify the recovery from sync lost error on rev1Bartosz Golaszewski1-9/+18
Revision 2 of LCDC suffers from an issue where a SYNC_LOST error caused by limited memory bandwidth may leave the picture shifted a couple pixels to the right. This issue has not been observed on revision 1, while the recovery mechanism introduces a different issue, where the END_OF_FRAME interrupt doesn't fire while drm is waiting for vblanks. On rev1: recover from sync lost errors by simply clearing the RASTER_ENABLE bit in the RASTER_CTRL register and re-enabling it again as is suggested by the datasheet. Signed-off-by: Bartosz Golaszewski <[email protected]> Reviewed-by: Jyri Sarha <[email protected]> Signed-off-by: Jyri Sarha <[email protected]>
2017-01-03drm/i915: Initialize num_scalers for skl and glk tooAnder Conselvan de Oliveira1-3/+6
After commit 1c74eeaf16b8 ("drm/i915: Move number of scalers initialization to runtime init"), scalers are not initialized properly for skl and glk since num_scalers is left as 0 for those platforms. Fixes: 1c74eeaf16b8 ("drm/i915: Move number of scalers initialization to runtime init") Cc: Nabendu Maiti <[email protected]> Cc: Chris Wilson <[email protected]> (v2) Cc: Ander Conselvan de Oliveira <[email protected]> Cc: Ander Conselvan de Oliveira <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Jani Nikula <[email protected]> Cc: [email protected] Signed-off-by: Ander Conselvan de Oliveira <[email protected]> Tested-by: Ville Syrjälä <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/1483365281-10569-1-git-send-email-ander.conselvan.de.oliveira@intel.com
2017-01-03drm/i915: Update comment in vlv_set_rps_idle()Chris Wilson1-2/+12
Ville explained that the wakelock was being acquired during set-idle in order to flush the voltage change from the punit. Signed-off-by: Chris Wilson <[email protected]> Cc: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Ville Syrjälä <[email protected]>
2017-01-03drm/i915/guc: Make intel_guc_recv static.Michal Wajdeczko2-4/+5
This function is only used by intel_guc_send() and it doesn't need to be exposed outside of intel_uc.o file. Also when defined as static, compiler will generate smaller code. Additionally let it take guc param instead dev_priv to match function name. Signed-off-by: Michal Wajdeczko <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Arkadiusz Hiler <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Signed-off-by: Tvrtko Ursulin <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-01-03drm/i915: Prevent timeline updates whilst performing resetChris Wilson1-1/+9
As the fence may be signaled concurrently from an interrupt on another device, it is possible for the list of requests on the timeline to be modified as we walk it. Take both (the context's timeline and the global timeline) locks to prevent such modifications. Fixes: 80b204bce8f2 ("drm/i915: Enable multiple timelines") Signed-off-by: Chris Wilson <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Mika Kuoppala <[email protected]> Cc: <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 00c25e3f40083a6d5f1111955baccd287ee49258) Signed-off-by: Jani Nikula <[email protected]>
2017-01-03drm/i915: Silence allocation failure during sg_trim()Chris Wilson1-1/+1
As trimming the sg table is merely an optimisation that gracefully fails if we cannot allocate a new table, we do not need to report the failure either. Fixes: 0c40ce130e38 ("drm/i915: Trim the object sg table") Signed-off-by: Chris Wilson <[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 8bfc478fa455b4908f745df368355b415460c60e) Signed-off-by: Jani Nikula <[email protected]>
2017-01-03drm/i915: Don't clflush before release phys objectChris Wilson1-4/+6
When we teardown the backing storage for the phys object, we copy from the coherent contiguous block back to the shmemfs object, clflushing as we go. Trying to clflush the invalid sg beforehand just oops and would be redundant (due to it already being coherent, and clflushed afterwards). Reported-by: Ville Syrjälä <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: <[email protected]> Reviewed-by: Joonas Lahtinen <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit e5facdf9644f4490520e0489a0252e8feaba3744) Signed-off-by: Jani Nikula <[email protected]>
2017-01-03drm/i915: Fix oops in overlay due to frontbuffer trackingVille Syrjälä1-2/+2
The vma will be NULL if the overlay was previously off, so dereferencing it will oops. Check for NULL before doing that. Cc: [email protected] Cc: Chris Wilson <[email protected]> Cc: Joonas Lahtinen <[email protected]> Fixes: 9b3b7841b86d ("drm/i915/overlay: Use VMA as the primary tracker for images") 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 4a15cdbbc55463e55a7cdcf33f84ccc742ca9c29) Signed-off-by: Jani Nikula <[email protected]>
2017-01-03drm/i915: Fix oopses in the overlay code due to i915_gem_active stuffVille Syrjälä2-1/+21
The i915_gem_active stuff doesn't like a NULL ->retire hook, but the overlay code can set it to NULL. That obviously ends up oopsing. Fix it by introducing a new helper to assign the retirement callback that will switch out the NULL function pointer with i915_gem_retire_noop. Cc: [email protected] Cc: Chris Wilson <[email protected]> Cc: Joonas Lahtinen <[email protected]> Fixes: 0d9bdd886f29 ("drm/i915: Convert intel_overlay to request tracking") Signed-off-by: Ville Syrjälä <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit ecd9caa0522db5a6b03ac8858c42067ef9d8323b) Signed-off-by: Jani Nikula <[email protected]>
2017-01-03drm/i915: Initialize overlay->last_flip properlyVille Syrjälä1-0/+2
Initialize overlay->last_flip properly instead of leaving it zeroed. Cc: [email protected] Cc: Chris Wilson <[email protected]> Fixes: 0d9bdd886f29 ("drm/i915: Convert intel_overlay to request tracking") Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 330afdb1df0f3fb48583105493a8f4f8d9e3af36) Signed-off-by: Jani Nikula <[email protected]>
2017-01-03drm/i915: Move the min_pixclk[] handling to the end of readoutVille Syrjälä1-16/+16
Trying to determine the pixel rate of the pipe can't be done until we know the clock, which means it can't be done until the encoder .get_config() hooks have been called. So let's move the min_pixclk[] stuff to the end of intel_modeset_readout_hw_state() when we actually have gathered all the required infromation. Cc: Maarten Lankhorst <[email protected]> Cc: Mika Kahola <[email protected]> Cc: Ander Conselvan de Oliveira <[email protected]> Fixes: 565602d7501a ("drm/i915: Do not acquire crtc state to check clock during modeset, v4.") 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]> Reviewed-by: Maarten Lankhorst <[email protected]> (cherry picked from commit aca1ebf491518910df156f3dab6a66306bb52e28) Signed-off-by: Jani Nikula <[email protected]>
2017-01-03drm/i915: Force VDD off on the new power seqeuencer before starting to use itVille Syrjälä1-7/+34
Apparently some VLV BIOSen like to leave the VDD force bit enabled even for power seqeuncers that aren't properly hooked up to any port. That will result in a imbalance in the AUX power domain refcount when we stat to use said power sequencer as edp_panel_vdd_on() will not grab the power domain reference if it sees that the VDD is already on. To fix this let's make sure we turn off the VDD force bit when we initialize the power sequencer registers. That is, unless it's being done from the init path since there we are actually initializing the registers for the current power sequencer and we don't want to turn VDD off needlessly as that would require waiting for the power cycle delay before we turn it back on. This fixes the following kind of warnings: WARNING: CPU: 0 PID: 123 at ../drivers/gpu/drm/i915/intel_runtime_pm.c:1455 intel_display_power_put+0x13a/0x170 [i915]() WARN_ON(!power_domains->domain_use_count[domain]) ... v2: Fix typos in comment (David) Cc: [email protected] Cc: Matwey V. Kornilov <[email protected]> Tested-by: Matwey V. Kornilov <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98695 Signed-off-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: David Weinehall <[email protected]> (cherry picked from commit 5d5ab2d26f32bdaa5872b938658e0bf8d341bc4c) Signed-off-by: Jani Nikula <[email protected]>
2017-01-03drm/meson: Fix plane atomic check when no crtc for the planeNeil Armstrong1-0/+3
When no CRTC is associated with the plane, the meson_plane_atomic_check() call breaks the kernel with an Oops. Fixes: bbbe775ec5b5 ("drm: Add support for Amlogic Meson Graphic Controller") Signed-off-by: Neil Armstrong <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.