summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2016-10-18drm/i915: Bump object bookkeeping to u64 from size_tChris Wilson3-4/+4
Internally we allow for using more objects than a single process can allocate, i.e. we allow for a 64bit GPU address space even on a 32bit system. Using size_t may oveerflow. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161018120251.25043-1-chris@chris-wilson.co.uk
2016-10-18drm/i915/gen9: don't call ilk_pipe_pixel_rate() twice on the same functionPaulo Zanoni1-2/+6
We used to call skl_pipe_pixel_rate(), which used to be a single one-line return, but now we're calling ilk_pipe_pixel_rate() which is not as simple, so it's better to just call it once and store the computed value for reuse. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1475872138-16194-2-git-send-email-paulo.r.zanoni@intel.com
2016-10-18drm/i915/gen9: fix watermarks when using the pipe scalerPaulo Zanoni1-9/+3
Luckily, the necessary adjustments for when we're using the scaler are exactly the same as the ones needed on ILK+, so just reuse the function we already have. v2: Invert the patch order so stable backports get easier. Cc: stable@vger.kernel.org Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1475872138-16194-1-git-send-email-paulo.r.zanoni@intel.com
2016-10-18drm/i915/gen9: look for adjusted_mode in the SAGV check for interlacedPaulo Zanoni1-1/+1
We want to look at the mode that we're actually going to set. All the other display checks for interlaced flags also look at adjusted_mode. Cc: Lyude <cpaul@redhat.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Lyude <cpaul@redhat.com> Link: http://patchwork.freedesktop.org/patch/msgid/1476131459-23763-2-git-send-email-paulo.r.zanoni@intel.com
2016-10-18drm/i915/gen9: unconditionally apply the memory bandwidth WAPaulo Zanoni1-8/+41
Mahesh Kumar is already working on a proper implementation for the workaround, but while we still don't have it, let's just unconditionally apply the workaround for everybody and we hope we can close all those numerous bugzilla tickets. Also, I'm not sure how easy it will be to backport the final implementation to the stable Kernels, and this patch here is probably easier to backport. At the present moment I still don't have confirmation that this patch fixes any of the bugs listed below, but we should definitely try testing all of them again. v2: s/intel_needs_memory_bw_wa/skl_needs_memory_bw_wa/ (Lyude). v3: Rebase (dev -> dev_priv change on ilk_wm_max_level). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94337 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94605 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94884 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95010 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96226 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96828 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97450 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97830 Cc: stable@vger.kernel.org Cc: Mahesh Kumar <mahesh1.kumar@intel.com> Cc: Lyude <cpaul@redhat.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Lyude <cpaul@redhat.com> Link: http://patchwork.freedesktop.org/patch/msgid/1476210338-9797-1-git-send-email-paulo.r.zanoni@intel.com
2016-10-18pinctrl: intel: Only restore pins that are used by the driverMika Westerberg1-2/+23
Dell XPS 13 (and maybe some others) uses a GPIO (CPU_GP_1) during suspend to explicitly disable USB touchscreen interrupt. This is done to prevent situation where the lid is closed the touchscreen is left functional. The pinctrl driver (wrongly) assumes it owns all pins which are owned by host and not locked down. It is perfectly fine for BIOS to use those pins as it is also considered as host in this context. What happens is that when the lid of Dell XPS 13 is closed, the BIOS configures CPU_GP_1 low disabling the touchscreen interrupt. During resume we restore all host owned pins to the known state which includes CPU_GP_1 and this overwrites what the BIOS has programmed there causing the touchscreen to fail as no interrupts are reaching the CPU anymore. Fix this by restoring only those pins we know are explicitly requested by the kernel one way or other. Cc: stable@vger.kernel.org Link: https://bugzilla.kernel.org/show_bug.cgi?id=176361 Reported-by: AceLan Kao <acelan.kao@canonical.com> Tested-by: AceLan Kao <acelan.kao@canonical.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-10-18pinctrl: baytrail: Fix lockdepVille Syrjälä1-1/+2
Initialize the spinlock before using it. INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.8.0-dwc-bisect #4 Hardware name: Intel Corp. VALLEYVIEW C0 PLATFORM/BYT-T FFD8, BIOS BLAKFF81.X64.0088.R10.1403240443 FFD8_X64_R_2014_13_1_00 03/24/2014 0000000000000000 ffff8800788ff770 ffffffff8133d597 0000000000000000 0000000000000000 ffff8800788ff7e0 ffffffff810cfb9e 0000000000000002 ffff8800788ff7d0 ffffffff8205b600 0000000000000002 ffff8800788ff7f0 Call Trace: [<ffffffff8133d597>] dump_stack+0x67/0x90 [<ffffffff810cfb9e>] register_lock_class+0x52e/0x540 [<ffffffff810d2081>] __lock_acquire+0x81/0x16b0 [<ffffffff810cede1>] ? save_trace+0x41/0xd0 [<ffffffff810d33b2>] ? __lock_acquire+0x13b2/0x16b0 [<ffffffff810cf05a>] ? __lock_is_held+0x4a/0x70 [<ffffffff810d3b1a>] lock_acquire+0xba/0x220 [<ffffffff8136f1fe>] ? byt_gpio_get_direction+0x3e/0x80 [<ffffffff81631567>] _raw_spin_lock_irqsave+0x47/0x60 [<ffffffff8136f1fe>] ? byt_gpio_get_direction+0x3e/0x80 [<ffffffff8136f1fe>] byt_gpio_get_direction+0x3e/0x80 [<ffffffff813740a9>] gpiochip_add_data+0x319/0x7d0 [<ffffffff81631723>] ? _raw_spin_unlock_irqrestore+0x43/0x70 [<ffffffff8136fe3b>] byt_pinctrl_probe+0x2fb/0x620 [<ffffffff8142fb0c>] platform_drv_probe+0x3c/0xa0 ... Based on the diff it looks like the problem was introduced in commit 71e6ca61e826 ("pinctrl: baytrail: Register pin control handling") but I wasn't able to verify that empirically as the parent commit just oopsed when I tried to boot it. Cc: Cristina Ciocan <cristina.ciocan@intel.com> Cc: stable@vger.kernel.org Fixes: 71e6ca61e826 ("pinctrl: baytrail: Register pin control handling") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-10-18pinctrl: aspeed-g5: Fix pin association of SPI1 functionAndrew Jeffery2-9/+81
The SPI1 function was associated with the wrong pins: The functions that those pins provide is either an SPI debug or passthrough function coupled to SPI1. Make the SPI1 mux function configure the relevant pins and associate new SPI1DEBUG and SPI1PASSTHRU functions with the pins that were already defined. The notation used in the datasheet's multi-function pin table for the SoC is often creative: in this case the SYS* signals are enabled by a single bit, which is nothing unusual on its own, but in this case the bit was also participating in a multi-bit bitfield and therefore represented multiple functions. This fact was overlooked in the original patch. Fixes: 56e57cb6c07f (pinctrl: Add pinctrl-aspeed-g5 driver) Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Joel Stanley <joel@jms.id.au> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-10-18pinctrl: aspeed-g5: Fix GPIOE1 typoAndrew Jeffery1-1/+1
This prevented C20 from successfully being muxed as GPIO. Fixes: 56e57cb6c07f (pinctrl: Add pinctrl-aspeed-g5 driver) Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-10-18pinctrl: aspeed-g5: Fix names of GPID2 pinsAndrew Jeffery1-6/+6
Fixes simple typos in the initial commit. There is no behavioural change. Fixes: 56e57cb6c07f (pinctrl: Add pinctrl-aspeed-g5 driver) Reported-by: Xo Wang <xow@google.com> Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-10-18pinctrl: aspeed: "Not enabled" is a significant mux stateAndrew Jeffery1-5/+7
Consider a scenario with one pin P that has two signals A and B, where A is defined to be higher priority than B: That is, if the mux IP is in a state that would consider both A and B to be active on P, then A will be the active signal. To instead configure B as the active signal we must configure the mux so that A is inactive. The mux state for signals can be described by logical operations on one or more bits from one or more registers (a "signal expression"), which in some cases leads to aliased mux states for a particular signal. Further, signals described by multi-bit bitfields often do not only need to record the states that would make them active (the "enable" expressions), but also the states that makes them inactive (the "disable" expressions). All of this combined leads to four possible states for a signal: 1. A signal is active with respect to an "enable" expression 2. A signal is not active with respect to an "enable" expression 3. A signal is inactive with respect to a "disable" expression 4. A signal is not inactive with respect to a "disable" expression In the case of P, if we are looking to activate B without explicitly having configured A it's enough to consider A inactive if all of A's "enable" signal expressions evaluate to "not active". If any evaluate to "active" then the corresponding "disable" states must be applied so it becomes inactive. For example, on the AST2400 the pins composing GPIO bank H provide signals ROMD8 through ROMD15 (high priority) and those for UART6 (low priority). The mux states for ROMD8 through ROMD15 are aliased, i.e. there are two mux states that result in the respective signals being configured: A. SCU90[6]=1 B. Strap[4,1:0]=100 Further, the second mux state is a 3-bit bitfield that explicitly defines the enabled state but the disabled state is implicit, i.e. if Strap[4,1:0] is not exactly "100" then ROMD8 through ROMD15 are not considered active. This requires the mux function evaluation logic to use approach 2. above, however the existing code was using approach 3. The problem was brought to light on the Palmetto machines where the strap register value is 0x120ce416, and prevented GPIO requests in bank H from succeeding despite the hardware being in a position to allow them. Fixes: 318398c09a8d ("pinctrl: Add core pinctrl support for Aspeed SoCs") Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-10-18drm/i915/guc: Sanitory checks for platform that dont have GuCAnusha Srivatsa1-5/+10
i915.enable_guc_loading/submission=2 forces the usage of GuC. For platforms that do not have a GuC, asking the kernel to use a GuC should not result in an error state. Do extra checks to see if the platform even has a GuC or not, regardless of the kernel parameter. v2: Based on Rodrigo's patch and Paulo's suggestion(Paulo, Rodrigo) v3: Correct the Indentation(Jani, Paulo) v4: Added the blank line(Jani, Paulo) v5 (from Paulo): Remove the extra blank line. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97573 Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Zanoni Paulo <paulo.r.zanoni@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1476488825-5673-1-git-send-email-anusha.srivatsa@intel.com
2016-10-18ceph: fix non static symbol warningWei Yongjun1-2/+2
Fixes the following sparse warning: fs/ceph/xattr.c:19:28: warning: symbol 'ceph_other_xattr_handler' was not declared. Should it be static? Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
2016-10-18locking, fs/locks: Add missing file_sem locksPeter Zijlstra1-0/+6
I overlooked a few code-paths that can lead to locks_delete_global_locks(). Reported-by: Dmitry Vyukov <dvyukov@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Jeff Layton <jlayton@poochiereds.net> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Bruce Fields <bfields@fieldses.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-fsdevel@vger.kernel.org Cc: syzkaller <syzkaller@googlegroups.com> Link: http://lkml.kernel.org/r/20161008081228.GF3142@twins.programming.kicks-ass.net Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-10-18locking/rwsem/x86: Add stack frame dependency for ____down_write()Josh Poimboeuf1-2/+4
Arnd reported the following objtool warning: kernel/locking/rwsem.o: warning: objtool: down_write_killable()+0x16: call without frame pointer save/setup The warning means gcc placed the ____down_write() inline asm (and its call instruction) before the frame pointer setup in down_write_killable(), which breaks frame pointer convention and can result in incorrect stack traces. Force the stack frame to be created before the call instruction by listing the stack pointer as an output operand in the inline asm statement. Reported-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/1188b7015f04baf361e59de499ee2d7272c59dce.1476393828.git.jpoimboe@redhat.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-10-18ceph: fix uninitialized dentry pointer in ceph_real_mount()Geert Uytterhoeven1-0/+2
fs/ceph/super.c: In function ‘ceph_real_mount’: fs/ceph/super.c:818: warning: ‘root’ may be used uninitialized in this function If s_root is already valid, dentry pointer root is never initialized, and returned by ceph_real_mount(). This will cause a crash later when the caller dereferences the pointer. Fixes: ce2728aaa82bbeba ("ceph: avoid accessing / when mounting a subpath") Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Yan, Zheng <zyan@redhat.com>
2016-10-18ceph: fix readdir vs fragmentation raceYan, Zheng1-1/+2
following sequence of events tigger the race - client readdir frag 0* -> got item 'A' - MDS merges frag 0* and frag 1* - client send readdir request (frag 1*, offset 2, readdir_start 'A') - MDS reply items (that are after item 'A') in frag * Link: http://tracker.ceph.com/issues/17286 Signed-off-by: Yan, Zheng <zyan@redhat.com>
2016-10-18drm: Don't export the drm_fb_get_bpp_depth() functionLaurent Pinchart3-34/+15
The function is only used by the drm_helper_mode_fill_fb_struct() core function to fill the drm_framebuffer bpp and depth fields, used by drivers that haven't been converted to use pixel formats directly yet. It should not be used by new drivers, so inline it in its only caller. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/1476744081-24485-14-git-send-email-laurent.pinchart@ideasonboard.com
2016-10-18drm/arm: mali-dp: Replace drm_fb_get_bpp_depth() with drm_format_plane_cpp()Laurent Pinchart1-6/+1
The driver doesn't need the color depth, only the number of bits per pixel. Use the right API. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/1476744081-24485-13-git-send-email-laurent.pinchart@ideasonboard.com
2016-10-18drm: vmwgfx: Replace drm_fb_get_bpp_depth() with drm_format_info()Laurent Pinchart1-2/+10
The driver is the last users of the drm_fb_get_bpp_depth() function. It should ideally be converted to use struct drm_mode_fb_cmd2 instead of the legacy struct drm_mode_fb_cmd internally, but that will require broad changes across the code base. As a first step, replace drm_fb_get_bpp_depth() with drm_format_info() in order to stop exporting the function to drivers. The new DRM_ERROR() message comes from the vmw_create_dmabuf_proxy(), vmw_kms_new_framebuffer_surface() and vmw_kms_new_framebuffer_dmabuf() functions that currently print an error if the pixel format is unsupported. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/1476744081-24485-12-git-send-email-laurent.pinchart@ideasonboard.com
2016-10-18drm: radeon: Replace drm_fb_get_bpp_depth() with drm_format_plane_cpp()Laurent Pinchart2-11/+12
The driver needs the number of bytes per pixel, not the bpp and depth info meant for fbdev compatibility. Use the right API. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/1476744081-24485-11-git-send-email-laurent.pinchart@ideasonboard.com
2016-10-18drm: amdgpu: Replace drm_fb_get_bpp_depth() with drm_format_plane_cpp()Laurent Pinchart2-8/+9
The driver needs the number of bytes per pixel, not the bpp and depth info meant for fbdev compatibility. Use the right API. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/1476744081-24485-10-git-send-email-laurent.pinchart@ideasonboard.com
2016-10-18drm: gma500: Replace drm_fb_get_bpp_depth() with drm_format_info()Laurent Pinchart1-11/+9
The driver uses drm_fb_get_bpp_depth() to check whether it can support the format requested by userspace when creating a framebuffer. This isn't the right API, as it doesn't differentiate between RGB formats other than on a depth and bpp basis. Fixing this requires non trivial changes to the drivers internals. As a first step, replace usage of the drm_fb_get_bpp_depth() function with an equivalent check based on drm_format_info(). This is part of a wider effort to remove usage of the drm_fb_get_bpp_depth() function in drivers. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/1476744081-24485-9-git-send-email-laurent.pinchart@ideasonboard.com
2016-10-18drm: cirrus: Replace drm_fb_get_bpp_depth() with drm_format_plane_cpp()Laurent Pinchart2-5/+5
The driver doesn't need the color depth, only the number of bits per pixel. Use the right API. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/1476744081-24485-8-git-send-email-laurent.pinchart@ideasonboard.com
2016-10-18drm: tilcdc: Replace drm_fb_get_bpp_depth() with drm_format_plane_cpp()Laurent Pinchart2-13/+12
The driver needs the number of bytes per pixel, not the bpp and depth info meant for fbdev compatibility. Use the right API. In the tilcdc_crtc_mode_set() function compute the hardware register value directly from the pixel format instead of computing the number of bits per pixels first. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/1476744081-24485-7-git-send-email-laurent.pinchart@ideasonboard.com
2016-10-18drm: hdlcd: Replace drm_fb_get_bpp_depth() with drm_format_plane_cpp()Laurent Pinchart1-3/+2
The driver needs the number of bytes per pixel, not the bpp and depth info meant for fbdev compatibility. Use the right API. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Liviu Dudau <Liviu.Dudau@arm.com> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/1476744081-24485-6-git-send-email-laurent.pinchart@ideasonboard.com
2016-10-18drm: WARN when calling drm_format_info() for an unsupported formatLaurent Pinchart3-9/+26
The format helpers have historically treated unsupported formats as part of the default case, returning values that are likely wrong. We can't change this behaviour now without risking breaking drivers in difficult to detect ways, but we can WARN on unsupported formats to catch faulty callers. The only exception is the framebuffer_check() function that calls drm_format_info() to validate the format passed from userspace. This is a valid use case that shouldn't generate a warning. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/1476744081-24485-5-git-send-email-laurent.pinchart@ideasonboard.com
2016-10-18drm: Use drm_format_info() in DRM core codeLaurent Pinchart2-100/+25
Replace calls to the drm_format_*() helper functions with direct use of the drm_format_info structure. This improves efficiency by removing duplicate lookups. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/1476744081-24485-4-git-send-email-laurent.pinchart@ideasonboard.com
2016-10-18drm: Implement the drm_format_*() helpers as drm_format_info() wrappersLaurent Pinchart1-149/+37
Turn the drm_format_*() helpers into wrappers around the drm_format_info lookup function to centralize all format information in a single place. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/1476744081-24485-3-git-send-email-laurent.pinchart@ideasonboard.com
2016-10-18drm: Centralize format informationLaurent Pinchart3-0/+108
Various pieces of information about DRM formats (number of planes, color depth, chroma subsampling, ...) are scattered across different helper functions in the DRM core. Callers of those functions often need to access more than a single parameter of the format, leading to inefficiencies due to multiple lookups. Centralize all format information in a data structure and create a function to look up information based on the format 4CC. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/1476744081-24485-2-git-send-email-laurent.pinchart@ideasonboard.com
2016-10-18drm/i915: Add lspcon resume functionShashank Sharma3-1/+15
As per the software design, we are driving lspcon in PCON mode. But while resuming from suspend, lspcon can go in LS mode (which is its default operating mode on power on) This patch adds a resume function for lspcon, which makes sure its operating in PCON mode, post resume. V2: Address review comments from Imre - move lspcon_resume call to encoder->reset() - use early returns Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1476455212-27893-6-git-send-email-shashank.sharma@intel.com
2016-10-18drm/i915: Enable lspcon initializationShashank Sharma1-1/+28
This patch adds initialization code for lspcon. What we are doing here is: - Check if lspcon is configured in VBT for this port - If lspcon is configured, initialize it and configure it as DP port. V2: Addressed Ville's review comments: - Not adding AVI IF functions for LSPCON display now. This part will be added once the dig_port level AVI-IF series gets merged. V3: Rebase V4: Rebase V5: Rebase V6: Rebase Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1476455212-27893-5-git-send-email-shashank.sharma@intel.com
2016-10-18drm/i915: Parse VBT data for lspconShashank Sharma2-0/+54
Many GEN9 boards come with on-board lspcon cards. Fot these boards, VBT configuration should properly point out if a particular port contains lspcon device, so that driver can initialize it properly. This patch adds a utility function, which checks the VBT flag for lspcon bit, and tells us if a port is configured to have a lspcon device or not. V2: Fixed review comments from Ville - Do not forget PORT_D while checking lspcon for GEN9 V3: Addressed review comments from Rodrigo - Create a HAS_LSPCON() macro for better use case handling. - Do not dump warnings for non-gen-9 platforms, it will be noise. V4: Rebase V5: Rebase V6: Pass dev_priv to HAS_LSPCON() macro Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1476455212-27893-4-git-send-email-shashank.sharma@intel.com
2016-10-18drm/i915: Add lspcon support for I915 driverShashank Sharma3-0/+138
This patch adds a new file, to accommodate lspcon support for I915 driver. These functions probe, detect, initialize and configure an on-board lspcon device during the driver init time. Also, this patch adds a small structure for lspcon device, which will provide the runtime status of the device. V2: addressed ville's review comments - Clean the leftover macros from previous patch set V3: Rebase V4: addressed ville's review comments - make internal functions static - remove lspcon_detect_identifier, make it inline with lspcon_probe - remove is_lspcon_active function - remove force check while setting a lspcon mode V5: Rebase V6: Pass dev_priv to IS_GEN9 check Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Akashdeep Sharma <akashdeep.sharma@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1476455212-27893-3-git-send-email-shashank.sharma@intel.com
2016-10-18drm: Helper for lspcon in drm_dp_dual_modeShashank Sharma2-0/+129
This patch adds lspcon support in dp_dual_mode helper. lspcon is essentially a dp->hdmi dongle with dual personality. LS mode: It works as a passive dongle, by level shifting DP++ signals to HDMI signals, in LS mode. PCON mode: It works as a protocol converter active dongle in pcon mode, by converting DP++ outputs to HDMI 2.0 outputs. This patch adds support for lspcon detection and mode set switch operations, as a dp dual mode dongle. v2: Addressed review comments from Ville - add adaptor id for lspcon devices (0x08), use it to identify lspcon - change function names old: drm_lspcon_get_current_mode/drm_lspcon_change_mode new: drm_lspcon_get_mode/drm_lspcon_set_mode - change drm_lspcon_get_mode type to int, to match drm_dp_dual_mode_get_tmds_output - change 'err' to 'ret' to match the rest of the functions - remove pointless typecasting during call to dual_mode_read - fix the but while setting value of data, while writing lspcon mode - fix indentation - change mdelay(10) -> msleep(10) - return ETIMEDOUT instead of EFAULT, when lspcon mode change times out - Add an empty line to separate std regs macros and lspcon regs macros Indent bit definition v3: Addressed review comments from Rodrigo - change macro name from DP_DUAL_MODE_TYPE_LSPCON to DP_DUAL_MODE_TYPE_HAS_DPCD for better readability - change macro name from DP_DUAL_MODE_LSPCON_MODE_PCON to DP_DUAL_MODE_LSPCON_MODE_PCON for better readability - add comment for MCA specific offsets like 0x40 and 0x41 - remove DP_DUAL_MODE_REV_TYPE2 check while checking lspcon adapter id v4: Addressed review comments from Ville - Fixed indentation at few places - s/current_mode/mode - s/reqd_mode/mode - remove unnecessary void* cast - remove drm_edid.h from includes - Add a comment for _HAS_DPCD - Fix enum description, for lspcon_mode. v5: Rebase v6: Rebase Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Dave Airlie <airlied@gmail.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1476720277-16298-1-git-send-email-shashank.sharma@intel.com
2016-10-18ext2: avoid bogus -Wmaybe-uninitialized warningArnd Bergmann1-3/+4
On ARM, we get this false-positive warning since the rework of the ext2_get_blocks interface: fs/ext2/inode.c: In function 'ext2_get_block': include/linux/buffer_head.h:340:16: error: 'bno' may be used uninitialized in this function [-Werror=maybe-uninitialized] The calling conventions for this function are rather complex, and it's not surprising that the compiler gets this wrong, I spent a long time trying to understand how it all fits together myself. This change to avoid the warning makes sure the compiler sees that we always set 'bno' pointer whenever we have a positive return code. The transformation is correct because we always arrive at the 'got_it' label with a positive count that gets used as the return value, while any branch to the 'cleanup' label has a negative or zero 'err'. Fixes: 6750ad71986d ("ext2: stop passing buffer_head to ext2_get_blocks") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Christoph Hellwig <hch@lst.de> Cc: Dave Chinner <david@fromorbit.com> Signed-off-by: Jan Kara <jack@suse.cz>
2016-10-18isofs: Do not return EACCES for unknown filesystemsJan Kara1-3/+5
When isofs_mount() is called to mount a device read-write, it returns EACCES even before it checks that the device actually contains an isofs filesystem. This may confuse mount(8) which then tries to mount all subsequent filesystem types in read-only mode. Fix the problem by returning EACCES only once we verify that the device indeed contains an iso9660 filesystem. CC: stable@vger.kernel.org Fixes: 17b7f7cf58926844e1dd40f5eb5348d481deca6a Reported-by: Kent Overstreet <kent.overstreet@gmail.com> Reported-by: Karel Zak <kzak@redhat.com> Signed-off-by: Jan Kara <jack@suse.cz>
2016-10-18drm: avoid uninitialized timestamp use in wait_vblankArnd Bergmann1-1/+3
gcc warns about the timestamp in drm_wait_vblank being possibly used without an initialization: drivers/gpu/drm/drm_irq.c: In function 'drm_crtc_send_vblank_event': drivers/gpu/drm/drm_irq.c:992:24: error: 'now.tv_usec' may be used uninitialized in this function [-Werror=maybe-uninitialized] drivers/gpu/drm/drm_irq.c:1069:17: note: 'now.tv_usec' was declared here drivers/gpu/drm/drm_irq.c:991:23: error: 'now.tv_sec' may be used uninitialized in this function [-Werror=maybe-uninitialized] This can happen if drm_vblank_count_and_time() returns 0 in its error path. To sanitize the error case, I'm changing that function to return a zero timestamp when it fails. Fixes: e6ae8687a87b ("drm: idiot-proof vblank") Reviewed-by: David Herrmann <dh.herrmann@gmail.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Mario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20161017221355.1861551-6-arnd@arndb.de
2016-10-18drm/i915/gvt: Fix build failure after intel_engine_cs changeZhenyu Wang3-5/+5
Change GVT-g code reference for intel_engine_cs from static array to allocated pointer after commit 3b3f1650b1ca ("drm/i915: Allocate intel_engine_cs structure only for the enabled engines"). Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20161018014007.29369-1-zhenyuw@linux.intel.com
2016-10-18btrfs: assign error values to the correct bio structsJunjie Mao1-2/+2
Fixes: 4246a0b63bd8 ("block: add a bi_error field to struct bio") Signed-off-by: Junjie Mao <junjie.mao@enight.me> Acked-by: David Sterba <dsterba@suse.cz> Cc: stable@vger.kernel.org # 4.3+ Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-10-18x86, pkeys: remove cruft from never-merged syscallsDave Hansen2-4/+0
pkey_set() and pkey_get() were syscalls present in older versions of the protection keys patches. The syscall number definitions were inadvertently left in place. This patch removes them. I did a git grep and verified that these are the last places in the tree that these appear, save for the protection_keys.c tests and Documentation. Those spots talk about functions called pkey_get/set() which are wrappers for the direct PKRU instructions, not the syscalls. Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-arch@vger.kernel.org Cc: mgorman@techsingularity.net Cc: arnd@arndb.de Cc: linux-api@vger.kernel.org Cc: linux-mm@kvack.org Cc: luto@kernel.org Cc: akpm@linux-foundation.org Fixes: f9afc6197e9bb ("x86: Wire up protection keys system calls") Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-10-17arm64: sysreg: Fix use of XZR in write_sysreg_sWill Deacon1-1/+1
Commit 8a71f0c656e0 ("arm64: sysreg: replace open-coded mrs_s/msr_s with {read,write}_sysreg_s") introduced a write_sysreg_s macro for writing to system registers that are not supported by binutils. Unfortunately, this was implemented with the wrong template (%0 vs %x0), so in the case that we are writing a constant 0, we will generate invalid instruction syntax and bail with a cryptic assembler error: | Error: constant expression required This patch fixes the template. Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-10-17hwmon: (max31790) potential ERR_PTR dereferenceDan Carpenter1-1/+3
We should only dereference "data" after we check if it is an error pointer. Fixes: 54187ff9d766 ('hwmon: (max31790) Convert to use new hwmon registration API') Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2016-10-17hwmon: (adm9240) handle temperature readings below 0Chris Packham1-3/+3
Unlike the temperature thresholds the temperature data is a 9-bit signed value. This allows and additional 0.5 degrees of precision on the reading but makes handling negative values slightly harder. In order to have sign-extension applied correctly the 9-bit value is stored in the upper bits of a signed 16-bit value. When presenting this in sysfs the value is shifted and scaled appropriately. Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2016-10-17generic syscalls: kill cruft from removed pkey syscallsDave Hansen2-7/+0
pkey_set() and pkey_get() were syscalls present in older versions of the protection keys patches. They were fully excised from the x86 code, but some cruft was left in the generic syscall code. The C++ comments were intended to help to make it more glaring to me to fix them before actually submitting them. That technique worked, but later than I would have liked. I test-compiled this for arm64. Fixes: a60f7b69d92c0 ("generic syscalls: Wire up memory protection keys syscalls") Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: x86@kernel.org Cc: linux-arch@vger.kernel.org Cc: mgorman@techsingularity.net Cc: linux-api@vger.kernel.org Cc: linux-mm@kvack.org Cc: luto@kernel.org Cc: akpm@linux-foundation.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-10-17irqchip/gic-v3-its: Fix entry size mask for GITS_BASERVladimir Murzin1-1/+1
Entry Size in GITS_BASER<n> occupies 5 bits [52:48], but we mask out 8 bits. Fixes: cc2d3216f53c ("irqchip: GICv3: ITS command queue") Cc: stable@vger.kernel.org Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2016-10-17arm64: kaslr: keep modules close to the kernel when DYNAMIC_FTRACE=yArd Biesheuvel1-1/+1
The RANDOMIZE_MODULE_REGION_FULL Kconfig option allows KASLR to be configured in such a way that kernel modules and the core kernel are allocated completely independently, which implies that modules are likely to require branches via PLT entries to reach the core kernel. The dynamic ftrace code does not expect that, and assumes that it can patch module code to perform a relative branch to anywhere in the core kernel. This may result in errors such as branch_imm_common: offset out of range ------------[ cut here ]------------ WARNING: CPU: 3 PID: 196 at kernel/trace/ftrace.c:1995 ftrace_bug+0x220/0x2e8 Modules linked in: CPU: 3 PID: 196 Comm: systemd-udevd Not tainted 4.8.0-22-generic #24 Hardware name: AMD Seattle/Seattle, BIOS 10:34:40 Oct 6 2016 task: ffff8d1bef7dde80 task.stack: ffff8d1bef6b0000 PC is at ftrace_bug+0x220/0x2e8 LR is at ftrace_process_locs+0x330/0x430 So make RANDOMIZE_MODULE_REGION_FULL mutually exclusive with DYNAMIC_FTRACE at the Kconfig level. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-10-17arm64: kernel: Init MDCR_EL2 even in the absence of a PMUMarc Zyngier1-1/+2
Commit f436b2ac90a0 ("arm64: kernel: fix architected PMU registers unconditional access") made sure we wouldn't access unimplemented PMU registers, but also left MDCR_EL2 uninitialized in that case, leading to trap bits being potentially left set. Make sure we always write something in that register. Fixes: f436b2ac90a0 ("arm64: kernel: fix architected PMU registers unconditional access") Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: <stable@vger.kernel.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-10-17perf: xgene: Remove bogus IS_ERR() checkTai Nguyen1-1/+1
In acpi_get_pmu_hw_inf we pass the address of a local variable to IS_ERR(), which doesn't make sense, as the pointer must be a real, valid pointer. This doesn't cause a functional problem, as IS_ERR() will evaluate as false, but the check is bogus and causes static checkers to complain. Remove the bogus check. The bug is reported by Dan Carpenter <dan.carpenter@oracle.com> in [1] [1] https://www.spinics.net/lists/arm-kernel/msg535957.html Signed-off-by: Tai Nguyen <ttnguyen@apm.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-10-17arm64: kernel: numa: fix ACPI boot cpu numa node mappingLorenzo Pieralisi1-0/+1
Commit 7ba5f605f3a0 ("arm64/numa: remove the limitation that cpu0 must bind to node0") removed the numa cpu<->node mapping restriction whereby logical cpu 0 always corresponds to numa node 0; removing the restriction was correct, in that it does not really exist in practice but the commit only updated the early mapping of logical cpu 0 to its real numa node for the DT boot path, missing the ACPI one, leading to boot failures on ACPI systems owing to missing node<->cpu map for logical cpu 0. Fix the issue by updating the ACPI boot path with code that carries out the early cpu<->node mapping also for the boot cpu (ie cpu 0), mirroring what is currently done in the DT boot path. Fixes: 7ba5f605f3a0 ("arm64/numa: remove the limitation that cpu0 must bind to node0") Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Reported-by: Laszlo Ersek <lersek@redhat.com> Cc: Will Deacon <will.deacon@arm.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Hanjun Guo <hanjun.guo@linaro.org> Cc: Andrew Jones <drjones@redhat.com> Cc: Zhen Lei <thunder.leizhen@huawei.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-30 14:53:29 +0300