- 06 Apr, 2016 40 commits
-
-
Takashi Iwai authored
BugLink: http://bugs.launchpad.net/bugs/1540390 Implement a new i915_audio_component_ops, get_eld(). It's called by the audio driver to fetch the current audio status and ELD of the given HDMI/DP port. It returns the size of expected ELD bytes if it's valid, zero if no valid ELD is found, or a negative error code. The current state of audio on/off is stored in the given pointer, too. Note that the returned size isn't limited to the given max bytes. If the size is greater than the max bytes, it means that only a part of ELD has been copied back. For achieving this implementation, a new field audio_connector is added to struct intel_digital_port. It points to the connector assigned to the given digital port. It's set/reset at each audio enable/disable call in intel_audio.c, and protected with av_mutex. Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Takashi Iwai <tiwai@suse.de> (cherry picked from commit cae666ce) Signed-off-by:
Timo Aaltonen <timo.aaltonen@canonical.com> Signed-off-by:
Andy Whitcroft <apw@canonical.com>
-
Chris Wilson authored
BugLink: http://bugs.launchpad.net/bugs/1540390 Since the beginning we have conflated the size of the global GTT with that of the per-process context sizes. In recent times (gen8+), those are no longer the same where the global GTT is limited to 2/4GiB but the per-process GTT may be anything up to 256TiB. Userspace knows nothing of this discrepancy and outside of one or two hacks, uses the getaperture ioctl to determine the maximum size it can use. Let's leave that as reporting the global GTT and use the context reporting method to describe the per-process value (which naturally fallsback to reporting the aliasing or global on older platforms, so userspace can always use this method where available). Testcase: igt/gem_userptr_blits/minor-normal-sync Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90065Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
-
Maarten Lankhorst authored
BugLink: http://bugs.launchpad.net/bugs/1540390 It can be useful to iterate over connectors without grabbing connection_mutex. It can also be used to see how many connectors are on a crtc without iterating over the list. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1451908400-25147-4-git-send-email-maarten.lankhorst@linux.intel.comSigned-off-by:
-
Maarten Lankhorst authored
BugLink: http://bugs.launchpad.net/bugs/1540390 The atomic helper sets connector_state->connector, which the i915 code didn't. This will become a problem when we start using it. Signed-off-by:
Thierry Reding <treding@nvidia.com> Link: http://patchwork.freedesktop.org/patch/msgid/1451908400-25147-1-git-send-email-maarten.lankhorst@linux.intel.comSigned-off-by:
-
Ville Syrjälä authored
BugLink: http://bugs.launchpad.net/bugs/1540390 Allow the caller to specify a "prefix" string to drm_rect_debug_print() to make it easier to see which drm_rect is being printed. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Thierry Reding authored
BugLink: http://bugs.launchpad.net/bugs/1540390 This function is like drm_modeset_lock_all(), but it takes the lock acquisition context as a parameter rather than storing it in the DRM device's mode_config structure. Implement drm_modeset_{,un}lock_all() in terms of the new function for better code reuse, and add a note to the kerneldoc that new code should use the new functions. v2: improve kerneldoc v4: rename drm_modeset_lock_all_crtcs() to drm_modeset_lock_all_ctx() and take mode_config's .connection_mutex instead of .mutex lock to avoid lock inversion (Daniel Vetter), use drm_modeset_drop_locks() which is now the equivalent of drm_modeset_unlock_all_ctx() v5: do not take the dev->mode_config.connection_mutex in drm_atomic_legacy_backoff() since drm_modeset_lock_all_ctx() already keeps it, enhance kerneldoc for drm_modeset_lock_all_ctx() (Daniel Vetter) Signed-off-by:
-
Libin Yang authored
BugLink: http://bugs.launchpad.net/bugs/1540390 This adds code to initialise the SDP streams for a sink in the simplest ordering. I've no idea how you'd want to control the ordering at this level, so don't bother until someone comes up with a use case. Reviewed-by:
Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by:
Libin Yang <libin.yang@linux.intel.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Jani Nikula authored
BugLink: http://bugs.launchpad.net/bugs/1540390 We have serious dangling else bugs waiting to happen in our for_each_ style macros with ifs. Consider, for example, #define drm_for_each_plane_mask(plane, dev, plane_mask) \ list_for_each_entry((plane), &(dev)->mode_config.plane_list, head) \ if ((plane_mask) & (1 << drm_plane_index(plane))) If this is used in context: if (condition) drm_for_each_plane_mask(plane, dev, plane_mask); else foo(); foo() will be called for each plane *not* in plane_mask, if condition holds, and not at all if condition doesn't hold. Fix this by reversing the conditions in the macros, and adding an else branch for the "for each" block, so that other if/else blocks can't interfere. Provide a "for_each_if" helper macro to make it easier to get this right. Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1448392916-2281-1-git-send-email-jani.nikula@intel.comSigned-off-by:
-
Lukas Wunner authored
BugLink: http://bugs.launchpad.net/bugs/1540390 Introduced by 84b233ad ("workqueue: implement current_is_async()"). Cc: Tejun Heo <tj@kernel.org> Signed-off-by:
Lukas Wunner <lukas@wunner.de> Acked-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Chris Wilson authored
BugLink: http://bugs.launchpad.net/bugs/1540390 Some modules, like i915.ko, use swappable objects and may try to swap them out under memory pressure (via the shrinker). Before doing so, they want to check using get_nr_swap_pages() to see if any swap space is available as otherwise they will waste time purging the object from the device without recovering any memory for the system. This requires the nr_swap_pages counter to be exported to the modules. Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Acked-by:
Johannes Weiner <hannes@cmpxchg.org> Signed-off-by:
-
Deepak S authored
BugLink: http://bugs.launchpad.net/bugs/1540390 v2: (Rodrigo) Rebase after commit 3cb27f38 ("drm/i915: remove an extra level of indirection in PCI ID list") Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
Deepak S <deepak.s@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446060072-19489-1-git-send-email-rodrigo.vivi@intel.comSigned-off-by:
-
Deepak S authored
BugLink: http://bugs.launchpad.net/bugs/1540390 v2: separate out device info into different GT (Damien) v3: Add is_kabylake to the KBL gt3 structuer (Damien) Sort the platforms in older -> newer order (Damien) v4: Split platform definition since is_skylake=1 on kabylake structure was Nacked. (Rodrigo) v5: (Rodrigo) Rebase after commit 3cb27f38 ("drm/i915: remove an extra level of indirection in PCI ID list") Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by:
-
Jani Nikula authored
BugLink: http://bugs.launchpad.net/bugs/1540390 Add the PCI IDs directly in the pciidlist array instead of defining an extra macro. The minor benefit from this is neater diffs when adding to the end of the list. v2: drop the "aka" comment (Ville) Reviewed-by:
-
Timo Aaltonen authored
BugLink: http://bugs.launchpad.net/bugs/1540390 Add i915_bpo_* functions for use with the ubuntu/i915 driver. i915_gpu_turbo_disable => i915_bpo_gpu_turbo_disable i915_gpu_busy => i915_bpo_gpu_busy i915_gpu_lower => i915_bpo_gpu_lower i915_gpu_raise => i915_bpo_gpu_raise i915_read_mch_val => i915_bpo_read_mch_val Signed-off-by:
-
Timo Aaltonen authored
BugLink: http://bugs.launchpad.net/bugs/1540390Signed-off-by:
-
Timo Aaltonen authored
BugLink: http://bugs.launchpad.net/bugs/1540390Signed-off-by:
-
Timo Aaltonen authored
BugLink: http://bugs.launchpad.net/bugs/1540390 Provide an updated i915 driver in the ubuntu directory. In subsequent patches we'll rename this driver to be i915_bpo and strictly limit it's support to only Skylake, Kabylake and Broxton. Keeping the initial sync a separate stand alone patch will allow us to easily update this driver again later. The driver is based on drm-intel-next-2016-02-14 tag. Signed-off-by:
-
Marc Zyngier authored
In order to avoid NTP messing with the guest timer behind our back, use the new and improved monotonic raw version of the hrtimers. Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com> Cc: Tomasz Nowicki <tn@semihalf.com> Cc: Christoffer Dall <christoffer.dall@linaro.org> Link: http://lkml.kernel.org/r/1452879670-16133-4-git-send-email-marc.zyngier@arm.comSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> (cherry picked from linux-next commit a6e707dd) BugLink: http://bugs.launchpad.net/bugs/1549494Signed-off-by:
dann frazier <dann.frazier@canonical.com> Signed-off-by:
-
Marc Zyngier authored
It is way too easy to take any random clockid and feed it to the hrtimer subsystem. At best, it gets mapped to a monotonic base, but it would be better to just catch illegal values as early as possible. This patch does exactly that, mapping illegal clockids to an illegal base index, and panicing when we detect the illegal condition. Signed-off-by:
-
Marc Zyngier authored
The KVM/ARM timer implementation arms a hrtimer when a vcpu is blocked (usually because it is waiting for an interrupt) while its timer is going to kick in the future. It is essential that this timer doesn't get adjusted, or the guest will end up being woken-up at the wrong time (NTP running on the host seems to confuse the hell out of some guests). In order to allow this, let's add CLOCK_MONOTONIC_RAW support to hrtimer (it is so far only supported for posix timers). It also has the (limited) benefit of fixing de0421d5 ("mac80211_hwsim: shuffle code to prepare for dynamic radios"), which already uses this functionnality without realizing wasn't implemented (just being lucky...). Signed-off-by:
-
Andy Whitcroft authored
Signed-off-by: -
Paolo Pisati authored
Calling apply_to_page_range with an empty range results in a BUG_ON from the core code. This can be triggered by trying to load the st_drv module with CONFIG_DEBUG_SET_MODULE_RONX enabled: kernel BUG at mm/memory.c:1874! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP Modules linked in: CPU: 3 PID: 1764 Comm: insmod Not tainted 4.5.0-rc1+ #2 Hardware name: ARM Juno development board (r0) (DT) task: ffffffc9763b8000 ti: ffffffc975af8000 task.ti: ffffffc975af8000 PC is at apply_to_page_range+0x2cc/0x2d0 LR is at change_memory_common+0x80/0x108 This patch fixes the issue by making change_memory_common (called by the set_memory_* functions) a NOP when numpages == 0, therefore avoiding the erroneous call to apply_to_page_range and bringing us into line with x86 and s390. Cc: <stable@vger.kernel.org> Reviewed-by:
Laura Abbott <labbott@redhat.com> Acked-by:
David Rientjes <rientjes@google.com> Signed-off-by:
Mika Penttilä <mika.penttila@nextfour.com> BugLink: http://bugs.launchpad.net/bugs/1547718Signed-off-by:
Paolo Pisati <paolo.pisati@canonical.com> Acked-by:
Brad Figg <brad.figg@canonical.com> Acked-by:
Kamal Mostafa <kamal@canonical.com> Signed-off-by:
-
Andy Whitcroft authored
Signed-off-by: -
Andy Whitcroft authored
Signed-off-by: -
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1536810Signed-off-by:
-
Seth Forshee authored
An overlayfs mount using an upper or lower directory from a nosuid filesystem bypasses this restriction. Change this so that if any lower or upper directory is nosuid at mount time the overlayfs superblock is marked nosuid. This requires some additions at the vfs level since nosuid currently only applies to mounts, so a SB_I_NOSUID flag is added along with a helper function to check a path for nosuid in both the mount and the superblock. BugLink: http://bugs.launchpad.net/bugs/1534961 BugLink: http://bugs.launchpad.net/bugs/1535150Signed-off-by:
Seth Forshee <seth.forshee@canonical.com> Signed-off-by:
-
Seth Forshee authored
When an overlayfs filesystem's lowerdir is on a nosuid filesystem but the upperdir is not, it's possible to copy up an sxid file or stick directory into upperdir without changing the mode by opening the file rw in the overlayfs mount without writing to it. This makes it possible to bypass the nosuid restriction on the lowerdir mount. It's a bad idea in general to let the mounter copy up a sxid file if the mounter wouldn't have had permission to create the sxid file in the first place. Therefore change ovl_set_xattr to exclude these bits when initially setting the mode, then set the full mode after setting the user for the inode. This allows copy up for non-sxid files to work as before but causes copy up to fail for the cases where the user could not have created the sxid inode in upperdir. BugLink: http://bugs.launchpad.net/bugs/1534961 BugLink: http://bugs.launchpad.net/bugs/1535150Signed-off-by:
-
Seth Forshee authored
The original mounter had CAP_SYS_ADMIN in the user namespace where the mount happened, and the vfs has validated that the user has permission to do the requested operation. This is sufficient for allowing the kernel to write these specific xattrs, so bypass the permission checks for these xattrs. BugLink: http://bugs.launchpad.net/bugs/1531747 BugLink: http://bugs.launchpad.net/bugs/1534961 BugLink: http://bugs.launchpad.net/bugs/1535150Signed-off-by:
-
Seth Forshee authored
When overlayfs needs to perform internal operations which require privileges the current user may not have, it does so by selectively raising the required capabilities in the current set of credentials. If the current process is in a user namespace this doesn't always work, as operations such as setting privileged xattrs often requires privileges in init_user_ns. These operations really ought to be permitted, based on a couple of facts: 1. The vfs has already verified that the current process is allowed to perform the requested operation on the overlayfs super block, and overlayfs has verified that the operation is permitted in upperdir. 2. The original mounter of the overlayfs super block was privileged enough to perform the internal overlayfs operations required to satisfy the user's request in upperdir. On the other hand, if the filesystem is mounted from a user namespace and then accessed in init_user_ns the credentials taken will exceed those of the mounter. This could result in performing operations that the user could not do otherwise, such as creating files which are sxid for another user or group. Both of these issues can be prevented by using the mounter's credentials when performing privileged overlayfs-internal operations. Add a new internal interface, ovl_prepare_creds(), which returns a new set of credentials for performing privileged internal operations that is identical to the mounter's creds. Use this internal interface instead of using prepare_creds() and selectively raising the needed capabilities. BugLink: http://bugs.launchpad.net/bugs/1531747 BugLink: http://bugs.launchpad.net/bugs/1534961 BugLink: http://bugs.launchpad.net/bugs/1535150Signed-off-by: -
Seth Forshee authored
This interface returns a new set of credentials which is an exact copy of another set. Also update prepare_kernel_cred() to use this function instead of duplicating code. BugLink: http://bugs.launchpad.net/bugs/1531747 BugLink: http://bugs.launchpad.net/bugs/1534961 BugLink: http://bugs.launchpad.net/bugs/1535150Signed-off-by:
-
Jesse Brandeburg authored
BugLink: http://bugs.launchpad.net/bugs/1547674 Bump. Change-ID: Ifa19aadaa892ad103f1b96fe2361fa690912c6a3 Signed-off-by:
Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> (cherry picked from net-next commit b8f1343a) Signed-off-by:
Tim Gardner <tim.gardner@canonical.com>
-
Mitch Williams authored
BugLink: http://bugs.launchpad.net/bugs/1547674 If we reset a VF, its VSI goes away, and it gets a new one. So don't hang on to the now-stale local VSI pointer. It just leads to suffering and kernel panics. Change-ID: Ia8823b4e85893e95e963acee284968022b29177a Signed-off-by:
Mitch Williams <mitch.a.williams@intel.com> Tested-by:
-
Pandi Kumar Maharajan authored
BugLink: http://bugs.launchpad.net/bugs/1547674 We need to suspend scheduling or any pending service task during driver unload process, so that new task will not be scheduled. This patch sets the suspend flag bit during reload which avoids service task execution. Change-ID: I017c57b5d6656564556e3c5387da671369a572ac Signed-off-by:
Pandi Kumar Maharajan <pandi.maharajan@intel.com> Tested-by:
-
Shannon Nelson authored
BugLink: http://bugs.launchpad.net/bugs/1547674 Use the new AdminQ functions for safely accessing the Rx control registers that may be affected by heavy small packet traffic. We can't use AdminQ calls in i40e_clear_hw() because the HW is being initialized and the AdminQ is not alive. We recently added an AQ related replacement for reading PFLAN_QALLOC, and this patch puts back the original register read. Change-ID: Ib027168c954a5733299aa3a4ce5f8218c6bb5636 Signed-off-by:
Shannon Nelson <shannon.nelson@intel.com> Tested-by:
-
Shannon Nelson authored
BugLink: http://bugs.launchpad.net/bugs/1547674 Use the new AdminQ functions for safely accessing the Rx control registers that may be affected by heavy small packet traffic. Change-ID: Ibb00983e8dcba71f4b760222a609a5fcaa726f18 Signed-off-by:
-
Shannon Nelson authored
BugLink: http://bugs.launchpad.net/bugs/1547674 Add the new opcodes and struct used for asking the firmware to update Rx control registers that need extra care when being accessed while under heavy traffic - e.g. sustained 64byte packets at line rate on all ports. The firmware will take extra steps to be sure the register accesses are successful. The registers involved are: PFQF_CTL_0 PFQF_HENA PFQF_FDALLOC PFQF_HREGION PFLAN_QALLOC VPQF_CTL VFQF_HENA VFQF_HREGION VSIQF_CTL VSILAN_QBASE VSILAN_QTABLE VSIQF_TCREGION PFQF_HKEY VFQF_HKEY PRTQF_CTL_0 GLFCOE_RCTL GLFCOE_RSOF GLQF_CTL GLQF_SWAP GLQF_HASH_MSK GLQF_HASH_INSET GLQF_HSYM GLQF_FC_MSK GLQF_FC_INSET GLQF_FD_MSK PRTQF_FD_INSET PRTQF_FD_FLXINSET PRTQF_FD_MSK Change-ID: I56c8144000da66ad99f68948d8a184b2ec2aeb3e Signed-off-by:
-
John Underwood authored
BugLink: http://bugs.launchpad.net/bugs/1547674 Return from i40e_vsi_reinit_setup() if vsi param is NULL. This makes this code consistent with all the other code that checks for NULL before using one of the VSI pointers accessed with an indexed variable. (Indexed VSI pointers are intentionally set to NULL in i40e_vsi_clear() and i40e_remove(). Change-ID: I3bc8b909c70fd2439334eeae994d151f61480985 Signed-off-by:
John Underwood <johnx.underwood@intel.com> Tested-by:
-
Anjali Singhai Jain authored
BugLink: http://bugs.launchpad.net/bugs/1547674 This patch adds 7 new register definitions for programming the parser, flow director and RSS blocks in the HW. Change-ID: I31e76673125275f3c69a14c646361919d04dc987 Signed-off-by:
Anjali Singhai Jain <anjali.singhai@intel.com> Tested-by:
-
Carolyn Wyborny authored
BugLink: http://bugs.launchpad.net/bugs/1547674 This fixes an issue where a previously removed message has returned. Changing the message type to dev_dbg leaves the info, if desired, but takes it out of normal everyday usage. Also changed call to only provide port data when its valid and not when its not (delete case). Change-ID: Ief6f33b915f6364c24fa8e5789c2fc3168b5e2ed Signed-off-by:
Carolyn Wyborny <carolyn.wyborny@intel.com> Tested-by:
-
Neerav Parikh authored
BugLink: http://bugs.launchpad.net/bugs/1547674 Just like Tx queues don't wait for Rx queues to be disabled before DCB has been reconfigured. Check the queues are disabled only after the DCB configuration has been applied to the VSI(s) managed by the PF driver. In case of any timeout issue a PF reset to recover. Change-ID: Ic51e94c25baf9a5480cee983f35d15575a88642c Signed-off-by:
Neerav Parikh <neerav.parikh@intel.com> Tested-by:
-
