1. 11 May, 2018 4 commits
    • Linus Torvalds's avatar
      Merge tag 'mtd/fixes-for-4.17-rc5' of git://git.infradead.org/linux-mtd · e03dc5d3
      Linus Torvalds authored
      Pull mtd fixes from Boris Brezillon:
      
       - make nand_soft_waitrdy() wait tWB before polling the status REG
      
       - fix BCH write in the the Marvell NAND controller driver
      
       - fix wrong picosec to msec conversion in the Marvell NAND controller
         driver
      
       - fix DMA handling in the TI OneNAND controllre driver
      
      * tag 'mtd/fixes-for-4.17-rc5' of git://git.infradead.org/linux-mtd:
        mtd: rawnand: Make sure we wait tWB before polling the STATUS reg
        mtd: rawnand: marvell: fix command xtype in BCH write hook
        mtd: rawnand: marvell: pass ms delay to wait_op
        mtd: onenand: omap2: Disable DMA for HIGHMEM buffers
      e03dc5d3
    • Linus Torvalds's avatar
      Merge tag 'drm-fixes-for-v4.17-rc5' of git://people.freedesktop.org/~airlied/linux · ca30093d
      Linus Torvalds authored
      Pull drm fixes from Dave Airlie:
       "nouveau, amdgpu, i915, vc4, omap, exynos and atomic fixes.
      
        As last week seemed a bit slow, we got a few more fixes this week.
      
        The main stuff is two weeks of fixes for amdgpu, some missing bits of
        vega12 atom firmware support were added, and some power management
        fixes.
      
        Nouveau got two regression fixes for an DP MST deadlock and a random
        oops fix.
      
        i915 got an LVDS panel timeout fix 2 WARN fixes.
      
        exynos fixed a pagefault issue in the mixer driver.
      
        vc4 has an oops fix.
      
        omap had a bunch of uninit var and error-checking fixes. Two atomic
        modesetting state fixes.
      
        One minor agp cleanup patch"
      
      * tag 'drm-fixes-for-v4.17-rc5' of git://people.freedesktop.org/~airlied/linux: (30 commits)
        drm/amd/pp: Fix performance drop on Fiji
        drm/nouveau: Fix deadlock in nv50_mstm_register_connector()
        drm/nouveau/ttm: don't dereference nvbo::cli, it can outlive client
        agp: uninorth: make two functions static
        drm/amd/pp: Refine the output of pp_power_profile_mode on VI
        drm/amdgpu: Switch to interruptable wait to recover from ring hang.
        drm/ttm: Use GFP_TRANSHUGE_LIGHT for allocating huge pages
        drm/amd/display: Use kvzalloc for potentially large allocations
        drm/amd/display: Don't return ddc result and read_bytes in same return value
        drm/amd/display: Add get_firmware_info_v3_2 for VG12
        drm/amd: Add BIOS smu_info v3_3 required struct def.
        drm/amd/display: Add VG12 ASIC IDs
        drm/vc4: Fix scaling of uni-planar formats
        drm/exynos: hdmi: avoid duplicating drm_bridge_attach
        drm/i915: Fix drm:intel_enable_lvds ERROR message in kernel log
        drm/i915: Correctly populate user mode h/vdisplay with pipe src size during readout
        drm/i915: Adjust eDP's logical vco in a reliable place.
        drm/bridge/sii8620: add Kconfig dependency on extcon
        drm/omap: handle alloc failures in omap_connector
        drm/omap: add missing linefeeds to prints
        ...
      ca30093d
    • Jann Horn's avatar
      compat: fix 4-byte infoleak via uninitialized struct field · 0a0b9873
      Jann Horn authored
      Commit 3a4d44b6 ("ntp: Move adjtimex related compat syscalls to
      native counterparts") removed the memset() in compat_get_timex().  Since
      then, the compat adjtimex syscall can invoke do_adjtimex() with an
      uninitialized ->tai.
      
      If do_adjtimex() doesn't write to ->tai (e.g.  because the arguments are
      invalid), compat_put_timex() then copies the uninitialized ->tai field
      to userspace.
      
      Fix it by adding the memset() back.
      
      Fixes: 3a4d44b6 ("ntp: Move adjtimex related compat syscalls to native counterparts")
      Signed-off-by: default avatarJann Horn <jannh@google.com>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Acked-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      0a0b9873
    • Dave Airlie's avatar
      Merge branch 'drm-fixes-4.17' of git://people.freedesktop.org/~agd5f/linux into drm-fixes · 72777fe7
      Dave Airlie authored
      Single amdgpu regression fix
      
      * 'drm-fixes-4.17' of git://people.freedesktop.org/~agd5f/linux:
        drm/amd/pp: Fix performance drop on Fiji
      72777fe7
  2. 10 May, 2018 12 commits
    • Linus Torvalds's avatar
      Merge tag 'for-4.17/dm-fixes' of... · 94d7dbf1
      Linus Torvalds authored
      Merge tag 'for-4.17/dm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
      
      Pull device mapper fixes from Mike Snitzer:
      
       - a stable fix for DM integrity to use kvfree
      
       - fix for a 4.17-rc1 change to dm-bufio's buffer alignment
      
       - fixes for a few sparse warnings
      
       - remove VLA usage in DM mirror target
      
       - improve DM thinp Documentation for the "read_only" feature
      
      * tag 'for-4.17/dm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
        dm thin: update Documentation to clarify when "read_only" is valid
        dm mirror: remove VLA usage
        dm: fix some sparse warnings and whitespace in dax methods
        dm cache background tracker: fix sparse warning
        dm bufio: fix buffer alignment
        dm integrity: use kvfree for kvmalloc'd memory
      94d7dbf1
    • Mike Snitzer's avatar
      dm thin: update Documentation to clarify when "read_only" is valid · 28700a36
      Mike Snitzer authored
      Due to user confusion, clarify that it doesn't make sense to try to
      create a thin-pool with "read_only" mode enabled.
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      28700a36
    • Rex Zhu's avatar
      drm/amd/pp: Fix performance drop on Fiji · 7fc6311b
      Rex Zhu authored
      The performance drop if the default TDP more than 256 Watt
      Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Reviewed-by: default avatarJunwei Zhang <Jerry.Zhang@amd.com>
      Signed-off-by: default avatarRex Zhu <Rex.Zhu@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      7fc6311b
    • Boris Brezillon's avatar
      mtd: rawnand: Make sure we wait tWB before polling the STATUS reg · 3057fcef
      Boris Brezillon authored
      NAND chips require a bit of time to take the NAND operation into
      account and set the BUSY bit in the STATUS reg. Make sure we don't poll
      the STATUS reg too early in nand_soft_waitrdy().
      
      Fixes: 8878b126 ("mtd: nand: add ->exec_op() implementation")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@bootlin.com>
      Acked-by: default avatarMiquel Raynal <miquel.raynal@bootlin.com>
      3057fcef
    • Dave Airlie's avatar
      Merge branch 'linux-4.17' of git://github.com/skeggsb/linux into drm-fixes · 7c2b1341
      Dave Airlie authored
      Two nouveau crasher/deadlock fixes.
      
      * 'linux-4.17' of git://github.com/skeggsb/linux:
        drm/nouveau: Fix deadlock in nv50_mstm_register_connector()
        drm/nouveau/ttm: don't dereference nvbo::cli, it can outlive client
      7c2b1341
    • Lyude Paul's avatar
      drm/nouveau: Fix deadlock in nv50_mstm_register_connector() · 352672db
      Lyude Paul authored
      Currently; we're grabbing all of the modesetting locks before adding MST
      connectors to fbdev. This isn't actually necessary, and causes a
      deadlock as well:
      
      ======================================================
      WARNING: possible circular locking dependency detected
      4.17.0-rc3Lyude-Test+ #1 Tainted: G           O
      ------------------------------------------------------
      kworker/1:0/18 is trying to acquire lock:
      00000000c832f62d (&helper->lock){+.+.}, at: drm_fb_helper_add_one_connector+0x2a/0x60 [drm_kms_helper]
      
      but task is already holding lock:
      00000000942e28e2 (crtc_ww_class_mutex){+.+.}, at: drm_modeset_backoff+0x8e/0x1c0 [drm]
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #3 (crtc_ww_class_mutex){+.+.}:
             ww_mutex_lock+0x43/0x80
             drm_modeset_lock+0x71/0x130 [drm]
             drm_helper_probe_single_connector_modes+0x7d/0x6b0 [drm_kms_helper]
             drm_setup_crtcs+0x15e/0xc90 [drm_kms_helper]
             __drm_fb_helper_initial_config_and_unlock+0x29/0x480 [drm_kms_helper]
             nouveau_fbcon_init+0x138/0x1a0 [nouveau]
             nouveau_drm_load+0x173/0x7e0 [nouveau]
             drm_dev_register+0x134/0x1c0 [drm]
             drm_get_pci_dev+0x8e/0x160 [drm]
             nouveau_drm_probe+0x1a9/0x230 [nouveau]
             pci_device_probe+0xcd/0x150
             driver_probe_device+0x30b/0x480
             __driver_attach+0xbc/0xe0
             bus_for_each_dev+0x67/0x90
             bus_add_driver+0x164/0x260
             driver_register+0x57/0xc0
             do_one_initcall+0x4d/0x323
             do_init_module+0x5b/0x1f8
             load_module+0x20e5/0x2ac0
             __do_sys_finit_module+0xb7/0xd0
             do_syscall_64+0x60/0x1b0
             entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      -> #2 (crtc_ww_class_acquire){+.+.}:
             drm_helper_probe_single_connector_modes+0x58/0x6b0 [drm_kms_helper]
             drm_setup_crtcs+0x15e/0xc90 [drm_kms_helper]
             __drm_fb_helper_initial_config_and_unlock+0x29/0x480 [drm_kms_helper]
             nouveau_fbcon_init+0x138/0x1a0 [nouveau]
             nouveau_drm_load+0x173/0x7e0 [nouveau]
             drm_dev_register+0x134/0x1c0 [drm]
             drm_get_pci_dev+0x8e/0x160 [drm]
             nouveau_drm_probe+0x1a9/0x230 [nouveau]
             pci_device_probe+0xcd/0x150
             driver_probe_device+0x30b/0x480
             __driver_attach+0xbc/0xe0
             bus_for_each_dev+0x67/0x90
             bus_add_driver+0x164/0x260
             driver_register+0x57/0xc0
             do_one_initcall+0x4d/0x323
             do_init_module+0x5b/0x1f8
             load_module+0x20e5/0x2ac0
             __do_sys_finit_module+0xb7/0xd0
             do_syscall_64+0x60/0x1b0
             entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      -> #1 (&dev->mode_config.mutex){+.+.}:
             drm_setup_crtcs+0x10c/0xc90 [drm_kms_helper]
             __drm_fb_helper_initial_config_and_unlock+0x29/0x480 [drm_kms_helper]
             nouveau_fbcon_init+0x138/0x1a0 [nouveau]
             nouveau_drm_load+0x173/0x7e0 [nouveau]
             drm_dev_register+0x134/0x1c0 [drm]
             drm_get_pci_dev+0x8e/0x160 [drm]
             nouveau_drm_probe+0x1a9/0x230 [nouveau]
             pci_device_probe+0xcd/0x150
             driver_probe_device+0x30b/0x480
             __driver_attach+0xbc/0xe0
             bus_for_each_dev+0x67/0x90
             bus_add_driver+0x164/0x260
             driver_register+0x57/0xc0
             do_one_initcall+0x4d/0x323
             do_init_module+0x5b/0x1f8
             load_module+0x20e5/0x2ac0
             __do_sys_finit_module+0xb7/0xd0
             do_syscall_64+0x60/0x1b0
             entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      -> #0 (&helper->lock){+.+.}:
             __mutex_lock+0x70/0x9d0
             drm_fb_helper_add_one_connector+0x2a/0x60 [drm_kms_helper]
             nv50_mstm_register_connector+0x2c/0x50 [nouveau]
             drm_dp_add_port+0x2f5/0x420 [drm_kms_helper]
             drm_dp_send_link_address+0x155/0x1e0 [drm_kms_helper]
             drm_dp_add_port+0x33f/0x420 [drm_kms_helper]
             drm_dp_send_link_address+0x155/0x1e0 [drm_kms_helper]
             drm_dp_check_and_send_link_address+0x87/0xd0 [drm_kms_helper]
             drm_dp_mst_link_probe_work+0x4d/0x80 [drm_kms_helper]
             process_one_work+0x20d/0x650
             worker_thread+0x3a/0x390
             kthread+0x11e/0x140
             ret_from_fork+0x3a/0x50
      
      other info that might help us debug this:
      Chain exists of:
        &helper->lock --> crtc_ww_class_acquire --> crtc_ww_class_mutex
       Possible unsafe locking scenario:
             CPU0                    CPU1
             ----                    ----
        lock(crtc_ww_class_mutex);
                                     lock(crtc_ww_class_acquire);
                                     lock(crtc_ww_class_mutex);
        lock(&helper->lock);
      
       *** DEADLOCK ***
      5 locks held by kworker/1:0/18:
       #0: 000000004a05cd50 ((wq_completion)"events_long"){+.+.}, at: process_one_work+0x187/0x650
       #1: 00000000601c11d1 ((work_completion)(&mgr->work)){+.+.}, at: process_one_work+0x187/0x650
       #2: 00000000586ca0df (&dev->mode_config.mutex){+.+.}, at: drm_modeset_lock_all+0x3a/0x1b0 [drm]
       #3: 00000000d3ca0ffa (crtc_ww_class_acquire){+.+.}, at: drm_modeset_lock_all+0x44/0x1b0 [drm]
       #4: 00000000942e28e2 (crtc_ww_class_mutex){+.+.}, at: drm_modeset_backoff+0x8e/0x1c0 [drm]
      
      stack backtrace:
      CPU: 1 PID: 18 Comm: kworker/1:0 Tainted: G           O      4.17.0-rc3Lyude-Test+ #1
      Hardware name: Gateway FX6840/FX6840, BIOS P01-A3         05/17/2010
      Workqueue: events_long drm_dp_mst_link_probe_work [drm_kms_helper]
      Call Trace:
       dump_stack+0x85/0xcb
       print_circular_bug.isra.38+0x1ce/0x1db
       __lock_acquire+0x128f/0x1350
       ? lock_acquire+0x9f/0x200
       ? lock_acquire+0x9f/0x200
       ? __ww_mutex_lock.constprop.13+0x8f/0x1000
       lock_acquire+0x9f/0x200
       ? drm_fb_helper_add_one_connector+0x2a/0x60 [drm_kms_helper]
       ? drm_fb_helper_add_one_connector+0x2a/0x60 [drm_kms_helper]
       __mutex_lock+0x70/0x9d0
       ? drm_fb_helper_add_one_connector+0x2a/0x60 [drm_kms_helper]
       ? ww_mutex_lock+0x43/0x80
       ? _cond_resched+0x15/0x30
       ? ww_mutex_lock+0x43/0x80
       ? drm_modeset_lock+0xb2/0x130 [drm]
       ? drm_fb_helper_add_one_connector+0x2a/0x60 [drm_kms_helper]
       drm_fb_helper_add_one_connector+0x2a/0x60 [drm_kms_helper]
       nv50_mstm_register_connector+0x2c/0x50 [nouveau]
       drm_dp_add_port+0x2f5/0x420 [drm_kms_helper]
       ? mark_held_locks+0x50/0x80
       ? kfree+0xcf/0x2a0
       ? drm_dp_check_mstb_guid+0xd6/0x120 [drm_kms_helper]
       ? trace_hardirqs_on_caller+0xed/0x180
       ? drm_dp_check_mstb_guid+0xd6/0x120 [drm_kms_helper]
       drm_dp_send_link_address+0x155/0x1e0 [drm_kms_helper]
       drm_dp_add_port+0x33f/0x420 [drm_kms_helper]
       ? nouveau_connector_aux_xfer+0x7c/0xb0 [nouveau]
       ? find_held_lock+0x2d/0x90
       ? drm_dp_dpcd_access+0xd9/0xf0 [drm_kms_helper]
       ? __mutex_unlock_slowpath+0x3b/0x280
       ? drm_dp_dpcd_access+0xd9/0xf0 [drm_kms_helper]
       drm_dp_send_link_address+0x155/0x1e0 [drm_kms_helper]
       drm_dp_check_and_send_link_address+0x87/0xd0 [drm_kms_helper]
       drm_dp_mst_link_probe_work+0x4d/0x80 [drm_kms_helper]
       process_one_work+0x20d/0x650
       worker_thread+0x3a/0x390
       ? process_one_work+0x650/0x650
       kthread+0x11e/0x140
       ? kthread_create_worker_on_cpu+0x50/0x50
       ret_from_fork+0x3a/0x50
      
      Taking example from i915, the only time we need to hold any modesetting
      locks is when changing the port on the mstc, and in that case we only
      need to hold the connection mutex.
      Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
      Cc: Karol Herbst <kherbst@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      352672db
    • Ben Skeggs's avatar
      drm/nouveau/ttm: don't dereference nvbo::cli, it can outlive client · 0d5a03c3
      Ben Skeggs authored
      Potentially responsible for some random OOPSes.
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      Cc: stable@vger.kernel.org [v4.15+]
      0d5a03c3
    • Dave Airlie's avatar
      Merge branch 'drm-fixes-4.17' of git://people.freedesktop.org/~agd5f/linux into drm-fixes · 5c0e0b45
      Dave Airlie authored
      A little bigger than normal since this is two weeks of fixes.
      - Atom firmware table updates for vega12
      - Fix fallout from huge page support
      - Fix up smu7 power profile interface to be consistent with vega
      - Misc other fixes
      
      * 'drm-fixes-4.17' of git://people.freedesktop.org/~agd5f/linux:
        drm/amd/pp: Refine the output of pp_power_profile_mode on VI
        drm/amdgpu: Switch to interruptable wait to recover from ring hang.
        drm/ttm: Use GFP_TRANSHUGE_LIGHT for allocating huge pages
        drm/amd/display: Use kvzalloc for potentially large allocations
        drm/amd/display: Don't return ddc result and read_bytes in same return value
        drm/amd/display: Add get_firmware_info_v3_2 for VG12
        drm/amd: Add BIOS smu_info v3_3 required struct def.
        drm/amd/display: Add VG12 ASIC IDs
      5c0e0b45
    • Dave Airlie's avatar
      Merge tag 'drm-misc-fixes-2018-05-09' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes · 44ef02c2
      Dave Airlie authored
      atomic: Clear state pointers on clear (Ville)
      vc4: Fix oops in dpi disable (Eric)
      omap: Various error-checking + uninitialized var fixes (Tomi)
      
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Eric Anholt <eric@anholt.net>
      Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
      
      * tag 'drm-misc-fixes-2018-05-09' of git://anongit.freedesktop.org/drm/drm-misc:
        drm/vc4: Fix scaling of uni-planar formats
        drm/bridge/sii8620: add Kconfig dependency on extcon
        drm/omap: handle alloc failures in omap_connector
        drm/omap: add missing linefeeds to prints
        drm/omap: handle error if scale coefs are not found
        drm/omap: check return value from soc_device_match
        drm/omap: fix possible NULL ref issue in tiler_reserve_2d
        drm/omap: fix uninitialized ret variable
        drm/omap: silence unititialized variable warning
        drm/vc4: Fix oops dereferencing DPI's connector since panel_bridge.
        drm/atomic: Clean private obj old_state/new_state in drm_atomic_state_default_clear()
        drm/atomic: Clean old_state/new_state in drm_atomic_state_default_clear()
      44ef02c2
    • Dave Airlie's avatar
      Merge tag 'drm-intel-fixes-2018-05-09' of... · 03a0a3e5
      Dave Airlie authored
      Merge tag 'drm-intel-fixes-2018-05-09' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
      
      - Increase LVDS panel timeout to 5s to avoid spurious *ERROR*
      - Fix 2 WARNS: BIOS framebuffer related (FDO #105992) and eDP cdclk mismatch
      
      * tag 'drm-intel-fixes-2018-05-09' of git://anongit.freedesktop.org/drm/drm-intel:
        drm/i915: Fix drm:intel_enable_lvds ERROR message in kernel log
        drm/i915: Correctly populate user mode h/vdisplay with pipe src size during readout
        drm/i915: Adjust eDP's logical vco in a reliable place.
      03a0a3e5
    • Dave Airlie's avatar
      Merge tag 'exynos-drm-fixes-for-v4.17-rc5' of... · 87bf742b
      Dave Airlie authored
      Merge tag 'exynos-drm-fixes-for-v4.17-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-fixes
      
      Fixup pagefault issue of mixer driver
      - it makes sure to check shadow register for interlace scan.
      - it corrects chroma_addr[1], height and vertical position values.
      And trivial cleanup
      - it just removes duplicated drm_bridge_attach.
      
      * tag 'exynos-drm-fixes-for-v4.17-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos:
        drm/exynos: hdmi: avoid duplicating drm_bridge_attach
        drm/exynos: mixer: avoid Oops in vp_video_buffer()
        drm/exynos/mixer: fix synchronization check in interlaced mode
      87bf742b
    • Mathieu Malaterre's avatar
      agp: uninorth: make two functions static · dec60f3a
      Mathieu Malaterre authored
      Both ‘uninorth_remove_memory’ and ‘null_cache_flush’ can be made
      static. So make them.
      
      Silence the following gcc warning (W=1):
      
        drivers/char/agp/uninorth-agp.c:198:5: warning: no previous prototype for ‘uninorth_remove_memory’ [-Wmissing-prototypes]
      
      and
      
        drivers/char/agp/uninorth-agp.c:473:6: warning: no previous prototype for ‘null_cache_flush’ [-Wmissing-prototypes]
      Signed-off-by: default avatarMathieu Malaterre <malat@debian.org>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      dec60f3a
  3. 09 May, 2018 12 commits
  4. 08 May, 2018 6 commits
    • Linus Torvalds's avatar
      Merge branch 'for-4.17-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata · 036db8bd
      Linus Torvalds authored
      Pull libata fixes from Tejun Heo:
       "An earlier commit to add reset control for embedded ahci controllers
        affected some of the hardware specific drivers and got reverted for
        now.
      
        Other than that, just per-device workarounds and trivial changes"
      
      * 'for-4.17-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata:
        driver core: add __printf verification to __ata_ehi_pushv_desc
        ata: fix spelling mistake: "directon" -> "direction"
        libata: Apply NOLPM quirk for SanDisk SD7UB3Q*G1001 SSDs
        libata: Apply NOLPM quirk for SAMSUNG MZMPC128HBFU-000MV SSD
        ata: ahci: mvebu: override ahci_stop_engine for mvebu AHCI
        libahci: Allow drivers to override stop_engine
        Revert "ata: ahci-platform: add reset control support"
      036db8bd
    • Linus Torvalds's avatar
      Merge tag 'pinctrl-v4.17-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl · 93a0d340
      Linus Torvalds authored
      Pull pin control fixes from Linus Walleij:
       "Here are three pin control fixes.
      
        The Intel fixes are the most serious and important things I had queued
        since it affects a large portion of deployed Chromebooks.
      
         - Two major fixes for the Intel Cherryview and Sunrisepoint pin
           controllers, adjusting numberspaces so that they get aligned with
           various messed-up numbers encoded into the BIOS.
      
         - A fix for the Meson driver GPIO pin range"
      
      * tag 'pinctrl-v4.17-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
        pinctrl: sunrisepoint: Align GPIO number space with Windows
        pinctrl: cherryview: Associate IRQ descriptors to irqdomain
        pinctrl: meson-axg: fix the range of aobus bank
      93a0d340
    • Linus Torvalds's avatar
      Merge tag 'gpio-v4.17-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio · 89240c67
      Linus Torvalds authored
      Pull GPIO fixes from Linus Walleij:
       "Sorry for lagging behind on sending the first batch of GPIO fixes for
        this cycle. Just too busy conferencing and the weather was too nice.
      
        Here it is anyway: some real important polishing on the error path
        facing userspace (tagged for stable as well) and some normal driver
        fixes.
      
         - Fix proper IRQ unmasking in the Aspeed driver.
      
         - Do not free unrequested descriptors on the errorpath when creating
           line handles from the userspace chardev requested GPIO lines.
      
         - Also fix the errorpath in the linehandle creation function.
      
         - Fix the get/set multiple GPIO lines for a few of the funky
           industrial GPIO cards on the ISA bus"
      
      * tag 'gpio-v4.17-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
        gpio: pcie-idio-24: Fix off-by-one error in get_multiple loop
        gpio: pcie-idio-24: Fix port memory offset for get_multiple/set_multiple callbacks
        gpio: pci-idio-16: Fix port memory offset for get_multiple callback
        gpio: fix error path in lineevent_create
        gpioib: do not free unrequested descriptors
        gpio: fix aspeed_gpio unmask irq
      89240c67
    • Florent Flament's avatar
      drm/i915: Fix drm:intel_enable_lvds ERROR message in kernel log · e8f48f96
      Florent Flament authored
      Fix `[drm:intel_enable_lvds] *ERROR* timed out waiting for panel to
      power on` in kernel log at boot time.
      
      Toshiba Satellite Z930 laptops needs between 1 and 2 seconds to power
      on its screen during Intel i915 DRM initialization. This currently
      results in a `[drm:intel_enable_lvds] *ERROR* timed out waiting for
      panel to power on` message appearing in the kernel log during boot
      time and when stopping the machine.
      
      This change increases the timeout of the `intel_enable_lvds` function
      from 1 to 5 seconds, letting enough time for the Satellite 930 LCD
      screen to power on, and suppressing the error message from the kernel
      log.
      
      This patch has been successfully tested on Linux 4.14 running on a
      Toshiba Satellite Z930.
      
      [vsyrjala: bump the timeout from 2 to 5 seconds to match the DP
       code and properly cover the max hw timeout of ~4 seconds, and
       drop the comment about the specific machine since this is not
       a particulary surprising issue, nor specific to that one machine]
      Signed-off-by: default avatarFlorent Flament <contact@florentflament.com>
      Cc: stable@vger.kernel.org
      Cc: Pavel Petrovic <ppetrovic@acm.org>
      Cc: Sérgio M. Basto <sergio@serjux.com>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103414
      References: https://bugzilla.kernel.org/show_bug.cgi?id=57591Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180419160700.19828-1-ville.syrjala@linux.intel.comReviewed-by: default avatarJani Nikula <jani.nikula@intel.com>
      (cherry picked from commit 280b54ad)
      Signed-off-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      e8f48f96
    • Ville Syrjälä's avatar
      drm/i915: Correctly populate user mode h/vdisplay with pipe src size during readout · 660d88e7
      Ville Syrjälä authored
      During state readout we first read out the pipe src size, store
      that information in the user mode h/vdisplay, but later on we overwrite
      that with the actual crtc timings. That makes our read out crtc state
      inconsistent with itself when the BIOS has enabled the panel fitter to
      scale the pipe contents. Let's preserve the pipe src size based
      information in the user mode to make things consistent again.
      
      This fixes a problem introduced by commit a2936e3d ("drm/i915:
      Use drm_mode_get_hv_timing() to populate plane clip rectangle")
      where the inconsistent state is now leading the plane clipping code
      to report a failure on account the plane dst coordinates not matching
      the user mode size. Previously we did the plane clipping based on
      the pipe src size instead and thus never noticed the inconsistency.
      
      The failure manifests as a WARN:
      [    0.762117] [drm:intel_dump_pipe_config [i915]] requested mode:
      [    0.762142] [drm:drm_mode_debug_printmodeline [drm]] Modeline 0:"1366x768" 60 72143 1366 1414 1446 1526 768 771 777 784 0x40 0xa
      ...
      [    0.762327] [drm:intel_dump_pipe_config [i915]] port clock: 72143, pipe src size: 1024x768, pixel rate 72143
      ...
      [    0.764666] [drm:drm_atomic_helper_check_plane_state [drm_kms_helper]] Plane must cover entire CRTC
      [    0.764690] [drm:drm_rect_debug_print [drm]] dst: 1024x768+0+0
      [    0.764711] [drm:drm_rect_debug_print [drm]] clip: 1366x768+0+0
      [    0.764713] ------------[ cut here ]------------
      [    0.764714] Could not determine valid watermarks for inherited state
      [    0.764792] WARNING: CPU: 4 PID: 159 at drivers/gpu/drm/i915/intel_display.c:14584 intel_modeset_init+0x3ce/0x19d0 [i915]
      ...
      
      Cc: FadeMind <fademind@gmail.com>
      Cc: Dave Jones <davej@codemonkey.org.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Reported-by: default avatarFadeMind <fademind@gmail.com>
      Reported-by: default avatarDave Jones <davej@codemonkey.org.uk>
      Tested-by: default avatarDave Jones <davej@codemonkey.org.uk>
      References: https://lists.freedesktop.org/archives/intel-gfx/2018-April/163186.html
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105992
      Fixes: a2936e3d ("drm/i915: Use drm_mode_get_hv_timing() to populate plane clip rectangle")
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180426163015.14232-1-ville.syrjala@linux.intel.comReviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Tested-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Tested-by: default avatarFadeMind <fademind@gmail.com>
      (cherry picked from commit bd4cd03c)
      Signed-off-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      660d88e7
    • Rodrigo Vivi's avatar
      drm/i915: Adjust eDP's logical vco in a reliable place. · 9d219554
      Rodrigo Vivi authored
      On intel_dp_compute_config() we were calculating the needed vco
      for eDP on gen9 and we stashing it in
      intel_atomic_state.cdclk.logical.vco
      
      However few moments later on intel_modeset_checks() we fully
      replace entire intel_atomic_state.cdclk.logical with
      dev_priv->cdclk.logical fully overwriting the logical desired
      vco for eDP on gen9.
      
      So, with wrong VCO value we end up with wrong desired cdclk, but
      also it will raise a lot of WARNs: On gen9, when we read
      CDCLK_CTL to verify if we configured properly the desired
      frequency the CD Frequency Select bits [27:26] == 10b can mean
      337.5 or 308.57 MHz depending on the VCO. So if we have wrong
      VCO value stashed we will believe the frequency selection didn't
      stick and start to raise WARNs of cdclk mismatch.
      
      [   42.857519] [drm:intel_dump_cdclk_state [i915]] Changing CDCLK to 308571 kHz, VCO 8640000 kHz, ref 24000 kHz, bypass 24000 kHz, voltage level 0
      [   42.897269] cdclk state doesn't match!
      [   42.901052] WARNING: CPU: 5 PID: 1116 at drivers/gpu/drm/i915/intel_cdclk.c:2084 intel_set_cdclk+0x5d/0x110 [i915]
      [   42.938004] RIP: 0010:intel_set_cdclk+0x5d/0x110 [i915]
      [   43.155253] WARNING: CPU: 5 PID: 1116 at drivers/gpu/drm/i915/intel_cdclk.c:2084 intel_set_cdclk+0x5d/0x110 [i915]
      [   43.170277] [drm:intel_dump_cdclk_state [i915]] [hw state] 337500 kHz, VCO 8100000 kHz, ref 24000 kHz, bypass 24000 kHz, voltage level 0
      [   43.182566] [drm:intel_dump_cdclk_state [i915]] [sw state] 308571 kHz, VCO 8640000 kHz, ref 24000 kHz, bypass 24000 kHz, voltage level 0
      
      v2: Move the entire eDP's vco logical adjustment to inside
          the skl_modeset_calc_cdclk as suggested by Ville.
      
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Fixes: bb0f4aab ("drm/i915: Track full cdclk state for the logical and actual cdclk frequencies")
      Cc: <stable@vger.kernel.org> # v4.12+
      Link: https://patchwork.freedesktop.org/patch/msgid/20180502175255.5344-1-rodrigo.vivi@intel.com
      (cherry picked from commit 3297234a)
      Signed-off-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      9d219554
  5. 07 May, 2018 6 commits