- 14 Jan, 2019 14 commits
-
-
Chris Wilson authored
Track the temporary wakerefs used within the selftests so that leaks are clear. v2: Add a couple of coarse annotations for mock selftests as we now loudly warn about the errors. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190114142129.24398-14-chris@chris-wilson.co.uk
-
Chris Wilson authored
Keep track of the temporary rpm wakeref used for panel backlight access, so that we can cancel it immediately upon release and so more clearly identify leaks. Signed-off-by:
-
Chris Wilson authored
Keep track of the temporary rpm wakeref inside hotplug detection, so that we can cancel it immediately upon release and so clearly identify leaks. Signed-off-by:
-
Chris Wilson authored
Keep track of the rpm wakeref used for framebuffer access so that we can cancel upon release and so more clearly identify leaks. Signed-off-by:
-
Chris Wilson authored
Keep track of the temporary rpm wakerefs used for user access to the device, so that we can cancel them upon release and clearly identify any leaks. Signed-off-by:
-
Chris Wilson authored
Keep track of our acquired wakeref for interacting with the guc, so that we can cancel it upon release and so clearly identify leaks. Signed-off-by:
-
Chris Wilson authored
Track the wakeref used for temporary access to the device, and discard it upon release so that leaks can be identified. Signed-off-by:
-
Chris Wilson authored
Keep track of our wakeref used to keep the device awake so we can catch any leak. Signed-off-by:
-
Chris Wilson authored
As debugfs has a simple pattern of taking a rpm wakeref around the user access, we can track the local reference and drop it as soon as possible. Signed-off-by:
-
Chris Wilson authored
As sysfs has a simple pattern of taking a rpm wakeref around the user access, we can track the local reference and drop it as soon as possible. Signed-off-by:
-
Chris Wilson authored
Keep hold of the local wakeref used in error handling, to cancel the tracking upon release so that leaks can be identified. Signed-off-by:
-
Chris Wilson authored
Record the wakeref used for keeping the device awake as the GPU is executing requests and be sure to cancel the tracking upon parking. Signed-off-by:
-
Chris Wilson authored
The majority of runtime-pm operations are bounded and scoped within a function; these are easy to verify that the wakeref are handled correctly. We can employ the compiler to help us, and reduce the number of wakerefs tracked when debugging, by passing around cookies provided by the various rpm_get functions to their rpm_put counterpart. This makes the pairing explicit, and given the required wakeref cookie the compiler can verify that we pass an initialised value to the rpm_put (quite handy for double checking error paths). For regular builds, the compiler should be able to eliminate the unused local variables and the program growth should be minimal. Fwiw, it came out as a net improvement as gcc was able to refactor rpm_get and rpm_get_if_in_use together, v2: Just s/rpm_put/rpm_put_unchecked/ everywhere, leaving the manual mark up for smaller more targeted patches. v3: Mention the cookie in Returns Signed-off-by:
-
Chris Wilson authored
Everytime we take a wakeref, record the stack trace of where it was taken; clearing the set if we ever drop back to no owners. For debugging a rpm leak, we can look at all the current wakerefs and check if they have a matching rpm_put. v2: Use skip=0 for unwinding the stack as it appears our noinline function doesn't appear on the stack (nor does save_stack_trace itself!) v3: Allow rpm->debug_count to disappear between inspections and so avoid calling krealloc(0) as that may return a ZERO_PTR not NULL! (Mika) v4: Show who last acquire/released the runtime pm Signed-off-by:
-
- 10 Jan, 2019 7 commits
-
-
Rodrigo Vivi authored
Signed-off-by:Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Chris Wilson authored
The wait-for-idle used from within the shrinker_lock_uninterruptible depends on the struct_mutex locking state being known and declared to i915_request_wait(). As it is conceivable that we reach the vmap notifier from underneath struct_mutex (and so keep on relying on the mutex_trylock_recursive), we should not blindly call i915_request_wait. In the process we can remove the dubious polling to acquire struct_mutex, and simply act, or not, on a successful trylock. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190109164204.23935-2-chris@chris-wilson.co.uk
-
Chris Wilson authored
If the current process is being killed (it was interrupted with SIGKILL or equivalent), it will not make any progress in page allocation and we can abort performing the shrinking on its behalf. So we can use mutex_lock_killable() instead (although this path should only be reachable from kswapd currently). Tvrtko pointed out that it should also be reachable from debugfs, which he would prefer retain its interruptiblity. As a compromise, killable is a step in the right direction! Signed-off-by:
-
Chris Wilson authored
If we find an incompletely setup vma inside the request/engine at the time of a hang, it may not have vma->pages initialised, so skip capturing the object before we iterate over NULL. Spotted by Matthew in preparation for using unpinned vma to track engine state. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190110111522.11023-1-chris@chris-wilson.co.uk
-
Daniele Ceraolo Spurio authored
The only gen8+ platform that has the feature is BDW, but we don't define the feature flag on any BDW platform and we only have partial support in the gen8 path (irq enabling code, but no handler). The only thing we could do in the irq handler is report the error to userspace, but no one asked/cared about that since BDW was released so it is relatively safe to assume that even if we added the message no one would look at it. Just drop the dead code from the driver instead. Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by:
-
Daniele Ceraolo Spurio authored
commit 4a15c75c ("drm/i915: Introduce per-engine workarounds") refactored the workaround code to have functions per-engine, but didn't call any of them from logical_xcs_ring_init. Since we do have a non-RCS workaround for KBL (WaKBLVECSSemaphoreWaitPoll) we do need to call intel_engine_init_workarounds for non-RCS engines. Note that whitelist is still RCS-only. v2: move the call to logical_ring_init (Chris) Fixes: 4a15c75c ("drm/i915: Introduce per-engine workarounds") Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Daniele Ceraolo Spurio authored
By using the wa lists inside the live driver structures, we won't catch issues where those are incorrectly setup or corrupted. To cover this gap, update the workaround framework to allow saving the wa lists to independent structures and use them in the selftests. Suggested-by:
-
- 09 Jan, 2019 6 commits
-
-
Chris Wilson authored
In the continual quest to reduce the amount of global work required when submitting requests, replace i915_retire_requests() after allocation failure to retiring just our ring. v2: Don't forget the list iteration included an early break, so we would never throttle on the last request in the ring/timeline. v3: Use the common ring_retire_requests() References: 11abf0c5 ("drm/i915: Limit the backpressure for i915_request allocation") Signed-off-by:
-
Hans de Goede authored
Add support for PMIC MIPI sequences using the new intel_soc_pmic_exec_mipi_pmic_seq_element function. This fixes the DSI LCD panel not lighting up when not initialized by the GOP (because an external monitor was connected) on GPD win and GPD pocket devices. Specifically the LCD panel seems to need GPIO pin 9 on the PMIC to be driven high, which is done through a PMIC MIPI sequence. Before this commit if the sequence was not executed by the GOP the pin would stay low causing the LCD panel to not work. Having the MIPI sequences properly control this GPIO should also help save some power when the panel is off. Changes in v2, v3: -Only changes to other patches in this patch-set Changes in v4: -Move decoding of the raw 15 bytes PMIC MIPI sequence element into i2c-address, register-address, value and mask into the mipi_exec_pmic() function instead of passing the raw data to intel_soc_pmic_exec_mipi_pmic_seq_element() Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190107111556.4510-5-hdegoede@redhat.com
-
Hans de Goede authored
Most PMIC-s use only a single i2c-address, so after verifying the i2c-address matches, we can simply pass the call to regmap_update_bits. This commit adds support for this and hooks this up for the xpower AXP288 PMIC by setting the new pmic_i2c_address field. This fixes the following errors on display on / off on a Jumper Ezpad mini 3 and an Onda V80 plus tablet, both of which use the AXP288: intel_soc_pmic_exec_mipi_pmic_seq_element: Not implemented intel_soc_pmic_exec_mipi_pmic_seq_element: i2c-addr: 0x34 reg-addr ... [drm:mipi_exec_pmic [i915]] *ERROR* mipi_exec_pmic failed, error: -95 Instead of these errors on both devices we now correctly turn on / off DLDO3 (through direct register manipulation). On the Onda V80 plus this fixes an issue with the backlight being brighter around the borders after an off / on cycle. This should also help to save some power when the display is off. Signed-off-by:
-
Hans de Goede authored
Implement the exec_mipi_pmic_seq_element callback for the CHT Whiskey Cove PMIC. On some CHT devices this fixes the LCD panel not lighting up when it was not initialized by the GOP, because an external monitor was plugged in and the GOP initialized only the external monitor. Reviewed-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
-
Hans de Goede authored
DSI LCD panels describe an initialization sequence in the Video BIOS Tables using so called MIPI sequences. One possible element in these sequences is a PMIC specific element of 15 bytes. Although this is not really an ACPI opregion, the ACPI opregion code is the closest thing we have. We need to have support for these PMIC specific MIPI sequence elements somwhere. Since we already instantiate a special platform device for Intel PMICs for the ACPI PMIC OpRegion handler to bind to, with PMIC specific implementations of the OpRegion, the handling of MIPI sequence PMIC elements fits very well in the ACPI PMIC OpRegion code. This commit adds a new intel_soc_pmic_exec_mipi_pmic_seq_element() function, which is to be backed by a PMIC specific exec_mipi_pmic_seq_element callback. This function will be called by the i915 code to execture MIPI sequence PMIC elements. Reviewed-by:
-
Jani Nikula authored
Needs just a few additional includes here and there. Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by:
Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190108082709.3748-1-jani.nikula@intel.com
-
- 08 Jan, 2019 5 commits
-
-
Chris Wilson authored
If we haven't shipped and enabled firmware for a particular platform, there is nothing the user can do about it. Don't scare the user with an unactionable, unidentifiable warning! <6> [310.769452] i915 0000:00:02.0: GuC: No firmware known for this platform! <4> [310.769458] [drm] HuC: No firmware known for this platform! Unify both GuC/HuC messages to include the device for which we lack the firmware, and provide the platform name as an aide-memoire. v2: Move and refine the message to common site of intel_uc_fw_fetch. Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190108150246.1471-1-chris@chris-wilson.co.uk
-
Jani Nikula authored
Minimal change to nuke the static buf. Reviewed-by:
-
Chris Wilson authored
Ignore trying to shrink from i915 if we fail to acquire the struct_mutex in the shrinker while performing direct-reclaim. The trade-off being (much) lower latency for non-i915 clients at an increased risk of being unable to obtain a page from direct-reclaim without hitting the oom-notifier. The proviso being that we still keep trying to hard obtain the lock for kswapd so that we can reap under heavy memory pressure. v2: Taint all mutexes taken within the shrinker with the struct_mutex subclass as an early warning system, and drop I915_SHRINK_ACTIVE from vmap to reduce the number of dangerous paths. We also have to drop I915_SHRINK_ACTIVE from oom-notifier to be able to make the same claim that ACTIVE is only used from outside context, which fits in with a longer strategy of avoiding stalls due to scanning active during shrinking. The danger in using the subclass struct_mutex is that we declare ourselves more knowledgable than lockdep and deprive ourselves of automatic coverage. Instead, we require ourselves to mark up any mutex taken inside the shrinker in order to detect lock-inversion, and if we miss any we are doomed to a deadlock at the worst possible moment. Signed-off-by:
-
Jani Nikula authored
Generally catch up with 5.0-rc1, and specifically get the changes: 96d4f267 ("Remove 'type' argument from access_ok() function") 0b2c8f8b ("i915: fix missing user_access_end() in page fault exception case") 594cc251 ("make 'user_access_begin()' do 'access_ok()'") Signed-off-by:
-
Jani Nikula authored
Merge tag 'topic/drmp-cleanup-2019-01-02' of git://anongit.freedesktop.org/drm/drm-intel into drm-intel-next-queued Make some drm headers self-contained with includes and forward declarations. This topic branch has already been merged to drm-misc-next as commit 1c95f662 ("Merge tag 'topic/drmp-cleanup-2019-01-02' of git://anongit.freedesktop.org/drm/drm-intel into drm-misc-next"). Now merge it to drm-intel-next-queued to unblock some further drmP.h cleanup without having to wait for a backmerge. Signed-off-by:
-
- 07 Jan, 2019 7 commits
-
-
Chris Wilson authored
Being a mock device, we suffer no DMA restrictions, so set the coherent mask to 64b. v2: Fix up mock_huge_selftests Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109243Signed-off-by:
-
Chris Wilson authored
Include the total size of closed vma when reporting the per_ctx_stats of debugfs/i915_gem_objects. Whilst adjusting the context tracking, note that we can simply use our list of contexts in i915->contexts rather than circumlocute via dev->filelist and the per-file context idr, with the result that we can show objects allocated to different vm (i.e. contexts within a file). We change the output to show every context of each client, with its own unique set of objects (for full-ppgtt machines, i.e. gen7+, for older hardware all objects are in the global gtt and so can not be associated with a single context). That should result in no loss of information, and for gen7+, no duplication of active objects. Signed-off-by:
-
Chris Wilson authored
Haswell also requires the RING_IMR flush for its unique vebox setup to avoid losing interrupts, as per 476af9c2 ("drm/i915/gen6: Flush RING_IMR changes before changing the global GT IMR"): On Baytail, notably, we can still detect missed interrupt syndrome (where we never spot a completed request). In this case, it can be alleviated by always keeping the interrupt unmasked, implying that the interrupt is being lost in the window after modifying the IMR. (This is the reason we still have the posting reads on enable_irq, if we remove them we miss interrupts!) Having narrowed the issue down to the IMR, rather than keeping it always enabled, applying the usual posting read/flush of the RING_IMR before unmasking the GT IMR also seems to prevent the missed interrupt. So be it. References: 476af9c2 ("drm/i915/gen6: Flush RING_IMR changes before changing the global GT IMR") Signed-off-by:
-
Chris Wilson authored
CC [M] drivers/gpu/drm/i915/intel_device_info.o drivers/gpu/drm/i915/intel_device_info.c:727: warning: Function parameter or member 'dev_priv' not described in 'intel_device_info_runtime_init' drivers/gpu/drm/i915/intel_device_info.c:727: warning: Excess function parameter 'info' description in 'intel_device_info_runtime_init' Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by:
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuildLinus Torvalds authored
Pull more Kbuild updates from Masahiro Yamada: - improve boolinit.cocci and use_after_iter.cocci semantic patches - fix alignment for kallsyms - move 'asm goto' compiler test to Kconfig and clean up jump_label CONFIG option - generate asm-generic wrappers automatically if arch does not implement mandatory UAPI headers - remove redundant generic-y defines - misc cleanups * tag 'kbuild-v4.21-3' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: kconfig: rename generated .*conf-cfg to *conf-cfg kbuild: remove unnecessary stubs for archheader and archscripts kbuild: use assignment instead of define ... endef for filechk_* rules arch: remove redundant UAPI generic-y defines kbuild: generate asm-generic wrappers if mandatory headers are missing arch: remove stale comments "UAPI Header export list" riscv: remove redundant kernel-space generic-y kbuild: change filechk to surround the given command with { } kbuild: remove redundant target cleaning on failure kbuild: clean up rule_dtc_dt_yaml kbuild: remove UIMAGE_IN and UIMAGE_OUT jump_label: move 'asm goto' support test to Kconfig kallsyms: lower alignment on ARM scripts: coccinelle: boolinit: drop warnings on named constants scripts: coccinelle: check for redeclaration kconfig: remove unused "file" field of yylval union nds32: remove redundant kernel-space generic-y nios2: remove unneeded HAS_DMA define
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull perf tooling updates form Ingo Molnar: "A final batch of perf tooling changes: mostly fixes and small improvements" * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (29 commits) perf session: Add comment for perf_session__register_idle_thread() perf thread-stack: Fix thread stack processing for the idle task perf thread-stack: Allocate an array of thread stacks perf thread-stack: Factor out thread_stack__init() perf thread-stack: Allow for a thread stack array perf thread-stack: Avoid direct reference to the thread's stack perf thread-stack: Tidy thread_stack__bottom() usage perf thread-stack: Simplify some code in thread_stack__process() tools gpio: Allow overriding CFLAGS tools power turbostat: Override CFLAGS assignments and add LDFLAGS to build command tools thermal tmon: Allow overriding CFLAGS assignments tools power x86_energy_perf_policy: Override CFLAGS assignments and add LDFLAGS to build command perf c2c: Increase the HITM ratio limit for displayed cachelines perf c2c: Change the default coalesce setup perf trace beauty ioctl: Beautify USBDEVFS_ commands perf trace beauty: Export function to get the files for a thread perf trace: Wire up ioctl's USBDEBFS_ cmd table generator perf beauty ioctl: Add generator for USBDEVFS_ ioctl commands tools headers uapi: Grab a copy of usbdevice_fs.h perf trace: Store the major number for a file when storing its pathname ...
-
- 06 Jan, 2019 1 commit
-
-
Linus Torvalds authored
The semantics of what "in core" means for the mincore() system call are somewhat unclear, but Linux has always (since 2.3.52, which is when mincore() was initially done) treated it as "page is available in page cache" rather than "page is mapped in the mapping". The problem with that traditional semantic is that it exposes a lot of system cache state that it really probably shouldn't, and that users shouldn't really even care about. So let's try to avoid that information leak by simply changing the semantics to be that mincore() counts actual mapped pages, not pages that might be cheaply mapped if they were faulted (note the "might be" part of the old semantics: being in the cache doesn't actually guarantee that you can access them without IO anyway, since things like network filesystems may have to revalidate the cache before use). In many ways the old semantics were somewhat insane even aside from the information leak issue. From the very beginning (and that beginning is a long time ago: 2.3.52 was released in March 2000, I think), the code had a comment saying Later we can get more picky about what "in core" means precisely. and this is that "later". Admittedly it is much later than is really comfortable. NOTE! This is a real semantic change, and it is for example known to change the output of "fincore", since that program literally does a mmmap without populating it, and then doing "mincore()" on that mapping that doesn't actually have any pages in it. I'm hoping that nobody actually has any workflow that cares, and the info leak is real. We may have to do something different if it turns out that people have valid reasons to want the old semantics, and if we can limit the information leak sanely. Cc: Kevin Easton <kevin@guarana.org> Cc: Jiri Kosina <jikos@kernel.org> Cc: Masatake YAMATO <yamato@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Greg KH <gregkh@linuxfoundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Michal Hocko <mhocko@suse.com> Signed-off-by:Linus Torvalds <torvalds@linux-foundation.org>
-
