aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2015-12-20drm/exynos: atomic check only enabled crtc statesAndrzej Hajda1-0/+3
Since atomic check is called also for disabled crtcs it should skip mode checking as it can be uninitialized. The patch fixes it. Signed-off-by: Andrzej Hajda <[email protected]> Suggested-by: Daniel Vetter <[email protected]> Tested-by: Javier Martinez Canillas <[email protected]> Signed-off-by: Inki Dae <[email protected]>
2015-12-19Merge branch 'linux-4.4' of git://github.com/skeggsb/linux into drm-fixesDave Airlie1-0/+1
single nouveau fix. * 'linux-4.4' of git://github.com/skeggsb/linux: drm/nouveau/bios/fan: hardcode the fan mode to linear
2015-12-19Merge branch 'drm-etnaviv-next' of git://git.pengutronix.de/git/lst/linux ↵Dave Airlie26-0/+7016
into drm-next here is the pull request for the etnaviv DRM driver. It includes the DT bindings and the driver itself, platform devicetree changes will be merged through the respective SoC trees. Otherwise it's just a squashed version of the V2 patches that have been on the list for a while. * 'drm-etnaviv-next' of git://git.pengutronix.de/git/lst/linux: MAINTAINERS: add maintainer and reviewers for the etnaviv DRM driver drm/etnaviv: add initial etnaviv DRM driver drm/etnaviv: add devicetree bindings devicetree: add vendor prefix for Vivante Corporation
2015-12-19Merge tag 'topic/drm-misc-2015-12-18' of ↵Dave Airlie59-203/+188
git://anongit.freedesktop.org/drm-intel into drm-next Seems I lied in my last drm-misc pull request and suddenly there's a big pile of random stuff. Boris dug out Thierry's drm-trivial branch and resubmitted everything since that branch didn't really work out. On top of that Nicolas' changes to drm_dev_set_unique - this might conflict with new driver pulls (I double checked and current drm-next should be fine), so please beware. The -next/-fixes conflict in vmwgfx will change slightly with this here too. * tag 'topic/drm-misc-2015-12-18' of git://anongit.freedesktop.org/drm-intel: (36 commits) drm: use dev_name as default unique name in drm_dev_alloc() drm: make drm_dev_set_unique() not use a format string drm/vmwgfx: Constify function pointer structs drm/udl: Constify function pointer structs drm/tegra: Constify function pointer structs drm/rockchip: Constify function pointer structs drm/nouveau: Constify function pointer structs drm/mgag200: Constify function pointer structs drm/imx: Constify function pointer structs drm/i2c/sil164: Constify function pointer structs drm/i2c/adv7511: Constify function pointer structs drm/exynos: Constify function pointer structs drm/cirrus: Constify function pointer structs drm/i2c/ch7006: Constify function pointer structs drm/bridge/nxp-ptn3460: Constify function pointer structs drm/bridge/dw_hdmi: Constify function pointer structs drm/bochs: Constify function pointer structs drm/atmel-hlcdc: Constify function pointer structs drm/armada: Constify function pointer structs drm: Constify drm_encoder_slave_funcs ...
2015-12-18drm/radeon: only increment sync_seq when a fence is really emittedNicolai Hähnle1-2/+2
In the rare situation where the kmalloc fails we're probably screwed anyway, but let's try to be more robust about it. Reviewed-by: Michel Dänzer <[email protected]> Signed-off-by: Nicolai Hähnle <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2015-12-18drm/radeon: fix typo in cik_ring_ib_execute documentation (v2)Nicolai Hähnle1-2/+2
v2: agd: clarify commit message, fix "an" as spotted by Michel. Reviewed-by: Michel Dänzer <[email protected]> Signed-off-by: Nicolai Hähnle <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2015-12-18drm/radeon: Update radeon_get_vblank_counter_kms()Thierry Reding1-12/+12
Commit 88e72717c2de ("drm/irq: Use unsigned int pipe in public API") updated the prototype of this function but not the implementation. This wasn't noticed even through compile tests because the prototype is part of the source file that uses it and hence the compiler won't know the prototype when it compiles the implementation. The right thing would've been to move the prototype to a header that's included in radeon_kms.c so that the implementation signature could be checked against it, but the closest thing would've been radeon_drv.h and including that results in a lot of build errors, so we'll leave it as is for now. Cc: Christian König <[email protected]> Cc: Alex Deucher <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2015-12-18drm/radeon: Fixup hw vblank counter/ts for new drm_update_vblank_count() (v2)Mario Kleiner9-29/+164
commit 4dfd6486 "drm: Use vblank timestamps to guesstimate how many vblanks were missed" introduced in Linux 4.4-rc1 makes the drm core more fragile to drivers which don't update hw vblank counters and vblank timestamps in sync with firing of the vblank irq and essentially at leading edge of vblank. This exposed a problem with radeon-kms/amdgpu-kms which do not satisfy above requirements: The vblank irq fires a few scanlines before start of vblank, but programmed pageflips complete at start of vblank and vblank timestamps update at start of vblank, whereas the hw vblank counter increments only later, at start of vsync. This leads to problems like off by one errors for vblank counter updates, vblank counters apparently going backwards or vblank timestamps apparently having time going backwards. The net result is stuttering of graphics in games, or little hangs, as well as total failure of timing sensitive applications. See bug #93147 for an example of the regression on Linux 4.4-rc: https://bugs.freedesktop.org/show_bug.cgi?id=93147 This patch tries to align all above events better from the viewpoint of the drm core / of external callers to fix the problem: 1. The apparent start of vblank is shifted a few scanlines earlier, so the vblank irq now always happens after start of this extended vblank interval and thereby drm_update_vblank_count() always samples the updated vblank count and timestamp of the new vblank interval. To achieve this, the reporting of scanout positions by radeon_get_crtc_scanoutpos() now operates as if the vblank starts radeon_crtc->lb_vblank_lead_lines before the real start of the hw vblank interval. This means that the vblank timestamps which are based on these scanout positions will now update at this earlier start of vblank. 2. The driver->get_vblank_counter() function will bump the returned vblank count as read from the hw by +1 if the query happens after the shifted earlier start of the vblank, but before the real hw increment at start of vsync, so the counter appears to increment at start of vblank in sync with the timestamp update. 3. Calls from vblank irq-context and regular non-irq calls are now treated identical, always simulating the shifted vblank start, to avoid inconsistent results for queries happening from vblank irq vs. happening from drm_vblank_enable() or vblank_disable_fn(). 4. The radeon_flip_work_func will delay mmio programming a pageflip until the start of the real vblank iff it happens to execute inside the shifted earlier start of the vblank, so pageflips now also appear to execute at start of the shifted vblank, in sync with vblank counter and timestamp updates. This to avoid some races between updates of vblank count and timestamps that are used for swap scheduling and pageflip execution which could cause pageflips to execute before the scheduled target vblank. The lb_vblank_lead_lines "fudge" value is calculated as the size of the display controllers line buffer in scanlines for the given video mode: Vblank irq's are triggered by the line buffer logic when the line buffer refill for a video frame ends, ie. when the line buffer source read position enters the hw vblank. This means that a vblank irq could fire at most as many scanlines before the current reported scanout position of the crtc timing generator as the number of scanlines the line buffer can maximally hold for a given video mode. This patch has been successfully tested on a RV730 card with DCE-3 display engine and on a evergreen card with DCE-4 display engine, in single-display and dual-display configuration, with different video modes. A similar patch is needed for amdgpu-kms to fix the same problem. Limitations: - Line buffer sizes in pixels are hard-coded on < DCE-4 to a value i just guessed to be high enough to work ok, lacking info on the true sizes atm. Fixes: fdo#93147 Signed-off-by: Mario Kleiner <[email protected]> Cc: Alex Deucher <[email protected]> Cc: Michel Dänzer <[email protected]> Cc: Harry Wentland <[email protected]> Cc: Ville Syrjälä <[email protected]> (v1) Tested-by: Dave Witbrodt <[email protected]> (v2) Refine radeon_flip_work_func() for better efficiency: In radeon_flip_work_func, replace the busy waiting udelay(5) with event lock held by a more performance and energy efficient usleep_range() until at least predicted true start of hw vblank, with some slack for scheduler happiness. Release the event lock during waits to not delay other outputs in doing their stuff, as the waiting can last up to 200 usecs in some cases. Retested on DCE-3 and DCE-4 to verify it still works nicely. (v2) Signed-off-by: Mario Kleiner <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2015-12-18drm/radeon: Fix "slow" audio over DP on DCE8+Slava Grigorev4-0/+29
DP audio is derived from the dfs clock. Signed-off-by: Slava Grigorev <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Cc: [email protected]
2015-12-18drm/amdgpu: keep the PTs validation list in the VM v2Christian König4-47/+27
This avoids allocating it on the fly. v2: fix grammar in comment Signed-off-by: Christian König <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Reviewed-by: Chunming Zhou <[email protected]>
2015-12-18drm/amdgpu: split VM PD and PT handling during CSChristian König4-29/+51
This way we avoid the extra allocation for the page directory entry. Signed-off-by: Christian König <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Reviewed-by: Chunming Zhou <[email protected]>
2015-12-18drm/amdgpu: put VM page tables directly into duplicates listChristian König4-9/+12
They share the reservation object with the page directory anyway. Signed-off-by: Christian König <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Reviewed-by: Chunming Zhou <[email protected]>
2015-12-18drm/amdgpu: restrict the sched jobs number to power of twoChunming Zhou2-2/+11
Signed-off-by: Chunming Zhou <[email protected]> Reviewed-by: Christian König <[email protected]> CC: [email protected]
2015-12-18drm/i915: Update DRIVER_DATE to 20151218Daniel Vetter1-1/+1
Signed-off-by: Daniel Vetter <[email protected]>
2015-12-18drm/i915/skl: Default to noncoherent access up to F0Mika Kuoppala1-5/+5
The workarounds for disabling hdc invalidation and also forcing context to be non coherent, are advised to be used up until rev D0. However as it was found that rev F0, without the WaForceEnableNonCoherent might system hang if the mesa tried to use coherent mode. As these two workarounds are about non coherent access, are grouped in scope and they point the same HSD, increase the scope of both to set default behaviour to non coherent access. References: HSD: gen9lp/2131413 References: http://lists.freedesktop.org/archives/mesa-dev/2015-November/101515.html Cc: Ben Widawsky <[email protected]> Cc: Francisco Jerez <[email protected]> Reviewed-by: Francisco Jerez <[email protected]> Signed-off-by: Mika Kuoppala <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2015-12-18drm/i915: Only spin whilst waiting on the current requestChris Wilson2-9/+26
Limit busywaiting only to the request currently being processed by the GPU. If the request is not currently being processed by the GPU, there is a very low likelihood of it being completed within the 2 microsecond spin timeout and so we will just be wasting CPU cycles. v2: Check for logical inversion when rebasing - we were incorrectly checking for this request being active, and instead busywaiting for when the GPU was not yet processing the request of interest. v3: Try another colour for the seqno names. v4: Another colour for the function names. v5: Remove the forced coherency when checking for the active request. On reflection and plenty of recent experimentation, the issue is not a cache coherency problem - but an irq/seqno ordering problem (timing issue). Here, we do not need the w/a to force ordering of the read with an interrupt. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Cc: "Rogozhkin, Dmitry V" <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Eero Tamminen <[email protected]> Cc: "Rantala, Valtteri" <[email protected]> Cc: [email protected] Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2015-12-18drm/i915: Limit the busy wait on requests to 5us not 10ms!Chris Wilson1-2/+45
When waiting for high frequency requests, the finite amount of time required to set up the irq and wait upon it limits the response rate. By busywaiting on the request completion for a short while we can service the high frequency waits as quick as possible. However, if it is a slow request, we want to sleep as quickly as possible. The tradeoff between waiting and sleeping is roughly the time it takes to sleep on a request, on the order of a microsecond. Based on measurements of synchronous workloads from across big core and little atom, I have set the limit for busywaiting as 10 microseconds. In most of the synchronous cases, we can reduce the limit down to as little as 2 miscroseconds, but that leaves quite a few test cases regressing by factors of 3 and more. The code currently uses the jiffie clock, but that is far too coarse (on the order of 10 milliseconds) and results in poor interactivity as the CPU ends up being hogged by slow requests. To get microsecond resolution we need to use a high resolution timer. The cheapest of which is polling local_clock(), but that is only valid on the same CPU. If we switch CPUs because the task was preempted, we can also use that as an indicator that the system is too busy to waste cycles on spinning and we should sleep instead. __i915_spin_request was introduced in commit 2def4ad99befa25775dd2f714fdd4d92faec6e34 [v4.2] Author: Chris Wilson <[email protected]> Date: Tue Apr 7 16:20:41 2015 +0100 drm/i915: Optimistically spin for the request completion v2: Drop full u64 for unsigned long - the timer is 32bit wraparound safe, so we can use native register sizes on smaller architectures. Mention the approximate microseconds units for elapsed time and add some extra comments describing the reason for busywaiting. v3: Raise the limit to 10us v4: Now 5us. Reported-by: Jens Axboe <[email protected]> Link: https://lkml.org/lkml/2015/11/12/621 Reviewed-by: Tvrtko Ursulin <[email protected]> Cc: "Rogozhkin, Dmitry V" <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Eero Tamminen <[email protected]> Cc: "Rantala, Valtteri" <[email protected]> Cc: [email protected] Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2015-12-18drm/i915: Break busywaiting for requests on pending signalsChris Wilson1-5/+8
The busywait in __i915_spin_request() does not respect pending signals and so may consume the entire timeslice for the task instead of returning to userspace to handle the signal. In the worst case this could cause a delay in signal processing of 20ms, which would be a noticeable jitter in cursor tracking. If a higher resolution signal was being used, for example to provide fairness of a server timeslices between clients, we could expect to detect some unfairness between clients (i.e. some windows not updating as fast as others). This issue was noticed when inspecting a report of poor interactivity resulting from excessively high __i915_spin_request usage. Fixes regression from commit 2def4ad99befa25775dd2f714fdd4d92faec6e34 [v4.2] Author: Chris Wilson <[email protected]> Date: Tue Apr 7 16:20:41 2015 +0100 drm/i915: Optimistically spin for the request completion v2: Try to assess the impact of the bug Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Cc: Jens Axboe <[email protected]> Cc; "Rogozhkin, Dmitry V" <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Eero Tamminen <[email protected]> Cc: "Rantala, Valtteri" <[email protected]> Cc: [email protected] Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2015-12-18drm/i915: don't enable autosuspend on platforms without RPM supportImre Deak1-5/+8
pm_runtime_{use,dont_use}_autosuspend() controls whether the device's sysfs power/autosuspend_delay_ms file is writeable or returns -EIO on access to user space. Since commit 25b181b46e4340f69793a886f2cd46608487783b Author: Imre Deak <[email protected]> Date: Thu Dec 17 13:44:56 2015 +0200 drm/i915: get a permanent RPM reference on platforms w/o RPM support this sysfs file is writeable also on platforms without RPM support, but userspace (at least IGT) depends on this file being unchangable to determine whether the device supports runtime PM at all. So restore the old behavior. This gets rid of igt/pm_rpm failures on old platforms without RPM support, where the test should be skipped. Testcase: igt/pm_rpm/basic-rte Signed-off-by: Imre Deak <[email protected]> Reviewed-by: David Weinehall <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2015-12-18drm/i915/backlight: prefer dev_priv over dev pointerJani Nikula1-98/+58
Use dev_priv rather than dev pointer where applicable. Remove plenty of unnecessary temp variables. No functional changes. Reviewed-by: Mika Kuoppala <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2015-12-18drm/nouveau/bios/fan: hardcode the fan mode to linearMartin Peres1-0/+1
This is an oversight that made use of the trip-point-based fan managenent on cards that never expose those. This led the fan to stay at fan_min. Fortunately, the emergency code would kick when the temperature would reach 90°C. Reported-by: Tom Englund <[email protected]> Tested-by: Tom Englund <[email protected]> Signed-off-by: Martin Peres <[email protected]> Tested-by: Daemon32 <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92126 Signed-off-by: Ben Skeggs <[email protected]> Cc: [email protected]
2015-12-17drm/vc4: fix an error codeDan Carpenter1-1/+1
"exec->exec_bo" is NULL at this point so this code returns success. We want to return -ENOMEM. Fixes: d5b1a78a772f ('drm/vc4: Add support for drawing 3D frames.') Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
2015-12-17drm/vc4: allocate enough memory in vc4_save_hang_state()Dan Carpenter1-1/+1
"state" is smaller than "kernel_state" so we end up corrupting memory. Fixes: 214613656b51 ('drm/vc4: Add an interface for capturing the GPU state after a hang.') Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
2015-12-17drm/vc4: copy_to_user() returns the number of bytes remainingDan Carpenter1-19/+18
The copy_to/from_user() functions return the number of bytes remaining to be copied. We want to return error codes here. Also it's a bad idea to print an error message if a copy from user fails because users can use that to spam /var/log/messages which is annoying so I removed those. Fixes: 214613656b51 ('drm/vc4: Add an interface for capturing the GPU state after a hang.') Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
2015-12-17drm/amdgpu: limit visible vram if it's smaller than the BARAlex Deucher2-0/+8
In some cases the amount of vram may be less than the BAR size, if so, limit visible vram to the amount of actual vram, not the BAR size. Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2015-12-17drm/i915: Disable primary plane if we fail to reconstruct BIOS fb (v2)Matt Roper1-0/+15
If we fail to reconstruct the BIOS fb (e.g., because the FB is too large), we'll be left with plane state that indicates the primary plane is visible yet has a NULL fb. This mismatch causes problems later on (e.g., for the watermark code). Since we've failed to reconstruct the BIOS FB, the best solution is to just disable the primary plane and pretend the BIOS never had it enabled. v2: Add intel_pre_disable_primary() call (Maarten) Cc: Daniel Vetter <[email protected]> Cc: Ville Syrjälä <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: [email protected] Signed-off-by: Matt Roper <[email protected]> Reviewed-by: Maarten Lankhorst <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2015-12-17drm/i915: Pin the ifbdev for the info->system_base GGTT mmappingChris Wilson1-7/+13
A long time ago (before 3.14) we relied on a permanent pinning of the ifbdev to lock the fb in place inside the GGTT. However, the introduction of stealing the BIOS framebuffer and reusing its address in the GGTT for the fbdev has muddied waters and we use an inherited fb. However, the inherited fb is only pinned whilst it is active and we no longer have an explicit pin for the info->system_base mmapping used by the fbdev. The result is that after some aperture pressure the fbdev may be evicted, but we continue to write the fbcon into the same GGTT address - overwriting anything else that may be put into that offset. The effect is most pronounced across suspend/resume as intel_fbdev_set_suspend() does a full clear over the whole scanout. v2: Only unpin the intel_fb is we allocate it. If we inherit the fb from the BIOS, we do not own the pinned vma (except for the reference we add in this patch for our access via info->screen_base). v3: Finish balancing the vma pinning for the normal !preallocated case. v4: Try to simplify the pinning even further. v5: Leak the VMA (cleaned up by object-free) to avoid complicated error paths. Signed-off-by: Chris Wilson <[email protected]> Cc: "Goel, Akash" <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Jesse Barnes <[email protected]> Cc: Lukas Wunner <[email protected]> Cc: [email protected] Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Tested-by: Ville Syrjälä <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-12-17drm/i915: Set the map-and-fenceable flag for preallocated objectsChris Wilson4-19/+27
As we mark the preallocated objects as bound, we should also flag them correctly as being map-and-fenceable (if appropriate!) so that later users do not get confused and try and rebind the pinned vma in order to get a map-and-fenceable binding. Signed-off-by: Chris Wilson <[email protected]> Cc: "Goel, Akash" <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Jesse Barnes <[email protected]> Cc: [email protected] Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jesse Barnes <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-12-17drm/i915: mdelay(10) considered harmfulDaniel Vetter1-1/+1
I missed this myself when reviewing commit 237ed86c693d8a8e4db476976aeb30df4deac74b Author: Sonika Jindal <[email protected]> Date: Tue Sep 15 09:44:20 2015 +0530 drm/i915: Check live status before reading edid Long sleeps like this really shouldn't waste cpu cycles spinning. Cc: Sonika Jindal <[email protected]> Cc: "Wang, Gary C" <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Sonika Jindal <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-12-17drm/i915: check that we are in an RPM atomic section in GGTT PTE updatersImre Deak1-0/+33
The device should be on for the whole duration of the update, so check for this. v2: - use the existing dev_priv directly everywhere (Ville) v3: - check also that we are in an RPM atomic section (Chris) - add the assert to i915_ggtt_insert_entries/clear_range too (Chris) Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2015-12-17drm/i915: add support for checking RPM atomic sectionsImre Deak4-1/+21
In some cases we want to check whether we hold an RPM wakelock reference for the whole duration of a sequence. To achieve this add a new RPM atomic sequence counter that we increment any time the wakelock refcount drops to zero. Check whether the sequence number stays the same during the atomic section and that we hold the wakelock at the beginning of the section. Motivated by Chris. v2-v3: - unchanged v4: - swap the order of atomic_read() and assert_rpm_wakelock_held() in assert_rpm_atomic_begin() to avoid race Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Chris Wilson <[email protected]> (v3) Reviewed-by: Joonas Lahtinen <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2015-12-17drm/i915: check that we hold an RPM wakelock ref before we put itImre Deak1-0/+1
With this change we have the corresponding wake lock checks in both the rpm get and put functions. v2-v3: - unchanged v4: - keep the corresponding check in the get helper (Chris) v5: - add a note to the commit message that with this change we have the checks both in the rpm get and put functions (Joonas) Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Joonas Lahtinen <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2015-12-17drm/i915: add support for checking if we hold an RPM referenceImre Deak7-10/+169
Atm, we assert that the device is not suspended until the point when the device is truly put to a suspended state. This is fine, but we can catch more problems if we check that RPM refcount is non-zero. After that one drops to zero we shouldn't access the device any more, even if the actual device suspend may be delayed. Change assert_rpm_wakelock_held() accordingly to check for a non-zero RPM refcount in addition to the current device-not-suspended check. For the new asserts to work we need to annotate every place explicitly in the code where we expect that the device is powered. The places where we only assume this, but may not hold an RPM reference: - driver load We assume the device to be powered until we enable RPM. Make this explicit by taking an RPM reference around the load function. - system and runtime sudpend/resume handlers These handlers are called when the RPM reference becomes 0 and know the exact point after which the device can get powered off. Disable the RPM-reference-held check for their duration. - the IRQ, hangcheck and RPS work handlers These handlers are flushed in the system/runtime suspend handler before the device is powered off, so it's guaranteed that they won't run while the device is powered off even though they don't hold any RPM reference. Disable the RPM-reference-held check for their duration. In all these cases we still check that the device is not suspended. These explicit annotations also have the positive side effect of documenting our assumptions better. This caught additional WARNs from the atomic modeset path, those should be fixed separately. v2: - remove the redundant HAS_RUNTIME_PM check (moved to patch 1) (Ville) v3: - use a new dedicated RPM wakelock refcount to also catch cases where our own RPM get/put functions were not called (Chris) - assert also that the new RPM wakelock refcount is 0 in the RPM suspend handler (Chris) - change the assert error message to be more meaningful (Chris) - prevent false assert errors and check that the RPM wakelock is 0 in the RPM resume handler too - prevent false assert errors in the hangcheck work too - add a device not suspended assert check to the hangcheck work v4: - rename disable/enable_rpm_asserts to disable/enable_rpm_wakeref_asserts and wakelock_count to wakeref_count - disable the wakeref asserts in the IRQ handlers and RPS work too - update/clarify commit message v5: - mark places we plan to change to use proper RPM refcounting with separate DISABLE/ENABLE_RPM_WAKEREF_ASSERTS aliases (Chris) Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2015-12-17drm/i915: use assert_rpm_wakelock_held instead of opencoding itImre Deak2-7/+5
Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2015-12-17drm/i915: add assert_rpm_wakelock_held helperImre Deak2-13/+21
As a preparation for follow-up patches add a new helper that checks whether we hold an RPM reference, since this is what we want most of the cases. Atm this helper will only check for the HW suspended state, a follow-up patch will do the actual change to check the refcount instead. One exception is the forcewake release timer function, where it's guaranteed that the HW is on even though the RPM refcount drops to zero. This guarantee is provided by flushing the timer in the runtime suspend handler. So leave the assert_device_not_suspended check in place there. Also rename assert_device_suspended for consistency and export these helpers as a preparation for the follow-up patches. No functional change. v3: - change the assert warning message to be more meaningful (Chris) Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2015-12-17drm/i915: remove HAS_RUNTIME_PM check from RPM get/put/assert helpersImre Deak2-11/+1
We don't really need to check this flag in the get/put/assert helpers, as on platforms without RPM support we won't ever enable RPM. That means pm.suspend will be always false and the assert will be always true. Do this to simplify the code and to let us extend the RPM asserts to all platforms for a better coverage. Motivated by Ville. v2-v3: - unchanged v4: - remove the HAS_RUNTIME_PM check from intel_runtime_pm_enable() too made possible by the previous two patches v5: - rebased on the previous new patch in the series that keeps HAS_RUNTIME_PM() in intel_runtime_pm_enable() with a permanent reference taken there Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Chris Wilson <[email protected]> (v3) Reviewed-by: Joonas Lahtinen <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2015-12-17drm/i915: get a permanent RPM reference on platforms w/o RPM supportImre Deak1-1/+16
Currently we disable RPM functionality on platforms that doesn't support this by not putting/getting the RPM reference we receive from the RPM core during driver loading/unloading respectively. This is somewhat obscure, so make it more explicit by keeping a reference dedicated for this particular purpose whenever the driver is loaded. This makes it possible to remove the HAS_RUNTIME_PM() special casing from every other places in the next patch. v2: - fix intel_runtime_pm_get vs. intel_runtime_pm_put in intel_power_domains_fini() v3: - take only a low level RPM reference so the ref tracking asserts continue to work (Ville) - update the commit message - move the patch earlier for bisectability Suggested-by: Ville Syrjälä <[email protected]> Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2015-12-17drm/i915: refactor RPM disabling due to RC6 being disabledImre Deak2-9/+15
We can make the RPM dependency on RC6 explcit in the code by taking an actual RPM reference, instead of avoiding to drop the initial one. This will also enable us to remove the HAS_RUNTIME_PM special casing from more places in the next patch. v2: - fixed typo in commit message (Joonas) Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Joonas Lahtinen <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2015-12-17drm/i915: clarify comment about mandatory RPM put/get during driver load/unloadImre Deak1-2/+13
Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Joonas Lahtinen <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2015-12-17drm/i915/opregion: handle VBT sizes bigger than 6 KBJani Nikula2-3/+25
The RVDA and RVDS (raw VBT data address and size) fields of the ASLE mailbox may specify an alternate location for VBT instead of mailbox #4. Use the alternate location if available and valid, falling back to mailbox #4 otherwise. v2: Update debug logging (Ville) Reviewed-by: Ville Syrjälä <[email protected]> Tested-by: Mika Kahola <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2015-12-16drm/amdgpu: fix user fence handlingChristian König2-22/+44
This fixes a random corruption under memory pressure. We need to fence the BO for the user fence as well, otherwise it might be swapped out and the GPU could write the fence value to an undesired location. Signed-off-by: Christian König <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2015-12-17Merge tag 'drm/tegra/for-4.5-rc1' of ↵Dave Airlie16-194/+944
git://anongit.freedesktop.org/tegra/linux into drm-next drm/tegra: Changes for v4.5-rc1 This adds support for the version of host1x found on Tegra210 SoCs. It also makes use of the new atomic suspend/resume functionality to bring this feature to Tegra. Other than that it's mostly small fixes and cleanups, with some prep- work for things that will hopefully get merged for the next release. * tag 'drm/tegra/for-4.5-rc1' of git://anongit.freedesktop.org/tegra/linux: drm/tegra: Advertise DRIVER_ATOMIC drm/tegra: Use DRIVER level for IOMMU aperture message drm/tegra: checking for IS_ERR() instead of NULL drm/tegra: dc: Add missing of_node_put() drm/tegra: Implement subsystem-level suspend/resume drm/tegra: sor: Remove unnecessary conditional drm/tegra: sor: Operate on struct drm_dp_aux * drm/tegra: Use drm_gem_object_unreference_unlocked() drm/tegra: Don't take dev->struct_mutex in mmap offset ioctl drm/tegra: Use unlocked gem unreferencing drm/tegra: Use new multi-driver module helpers gpu: host1x: Add Tegra210 support gpu: host1x: Remove core driver on unregister gpu: host1x: Use platform_register/unregister_drivers()
2015-12-17Merge tag 'drm/panel/for-4.5-rc1' of ↵Dave Airlie12-6/+908
git://anongit.freedesktop.org/tegra/linux into drm-next drm/panel: Changes for v4.5-rc1 This set of changes brings in a few more helpers for DSI support as well as a couple of new drivers and support for some more simple panels. * tag 'drm/panel/for-4.5-rc1' of git://anongit.freedesktop.org/tegra/linux: drm/panel: simple: Add QiaoDian qd43003c0-40 of: Add vendor prefix for QiaoDian Xianshi drm/panel: add kernel doc for size attributes in panel_desc drm/panel: simple: Add support for Kyocera TCG121XGLP panel devicetree: add vendor prefix for Kyocera Corporation drm/bridge: Remove gratuitous blank line drm/bridge: dw-hdmi: Use dashes in filenames drm/panel: Add Sharp LS043T1LE01 MIPI DSI panel dt-bindings: Add Sharp LS043T1LE01 panel binding drm/dsi: Add Turn On/Shutdown Peripheral command helpers drm/panel: Add Panasonic VVX10F034N00 MIPI DSI panel dt-bindings: Add Panasonic VVX10F034N00 panel binding drm/panel: simple: Add support for Innolux G121X1-L03 drm/panel: simple: Add support for BOE TV080WUM-NL0 dt-bindings: Add BOE TV080WUM-NL0 panel binding of: Add vendor prefix for BOE Technology Group drm/dsi: Add a helper to get bits per pixel of MIPI DSI pixel format
2015-12-16drm/panel: simple: Add QiaoDian qd43003c0-40Josh Wu1-0/+27
The QiaoDian Xianshi QD43003C0-40 is a 4"3 TFT LCD panel. Timings from the OTA5180A document, ver 0.9, section 10.1.1: http://www.orientdisplay.com/pdf/OTA5180A.pdf Signed-off-by: Josh Wu <[email protected]> Signed-off-by: Alexandre Belloni <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2015-12-16drm/i915: Fix AVI/HDMI/SPD infoframes on HSW+Ville Syrjälä1-6/+4
I broke AVI/HDMI/SPD infoframes on HSW+ with the register type safety changes. We were supposed to check that the infoframe data register is valid before writing the infoframe data, but the check ended up inverted, and so in practice we never wrote or enabled these infoframes. We were still sending out the GCP infoframe when the sink was deep-color capable. That and the fact that we use a single bool to track our infoframe state meant that the state checker only caught this when a HDMI sink that doesn't do deep-color was used. We really need to fix our infoframe state checking to be much more anal. But in the meantime let's just fix the regression. In fact let's just throw out the register validity check and convert some of the "unknown info frame type" debug messages into MISSING_CASE(). So far we support the same set of infoframe types on all platforms, so the silent debug messages make no sense. Cc: [email protected] Fixes: f0f59a00a1c9 ("drm/i915: Type safe register read/write") Reviewed-by: Maarten Lankhorst <[email protected]> (irc) Tested-by: Maarten Lankhorst <[email protected]> (irc) Signed-off-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93119 Reviewed-by: Daniel Vetter <[email protected]>
2015-12-16drm/i915/bios: reduce indent in parse_general_featuresJani Nikula1-19/+20
Slightly cleaner with early exit. Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2015-12-16drm/i915/bios: prefer using dev_priv over dev pointerJani Nikula3-15/+11
dev_priv is the new black. Or something. Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2015-12-16drm/i915/bios: fix format string of the VBT signature loggingJani Nikula1-2/+2
Specify the maximum number of letters to print from the potentially unterminated buffer, not the minimum. While at it, use sizeof instead of a magic number. Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2015-12-16drm/i915: move drmP.h include to i915_drv.hJani Nikula2-2/+1
The intel_bios.h header doesn't even need it, but other headers included from i915_drv.h do. Let's untangle the mess a bit. Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2015-12-16drm/panel: add kernel doc for size attributes in panel_descUlrich Ölmann1-0/+4
Document that 'width' and 'height' are measured in millimeters. Signed-off-by: Ulrich Ölmann <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.