1. 06 Aug, 2015 3 commits
  2. 06 Jul, 2015 1 commit
  3. 05 Jul, 2015 10 commits
    • Chris Zhong's avatar
      ARM: rockchip: remove some useless macro in pm.h · e6ef15e4
      Chris Zhong authored
      These are actually not used in the pm code, as we moved suspend handling
      to the clock driver, remove them here.
      Signed-off-by: default avatarChris Zhong <zyw@rock-chips.com>
      Reviewed-by: default avatarDouglas Anderson <dianders@chromium.org>
      Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      e6ef15e4
    • Chris Zhong's avatar
      ARM: rockchip: add support holding 24Mhz osc during suspend · 134f1f60
      Chris Zhong authored
      If we want to wake up system via usb, the 24Mhz osc could not be
      disabled during suspend, read the usb phy SIDDQ bit to decide whether
      to switch to 32khz clock-in.
      Signed-off-by: default avatarChris Zhong <zyw@rock-chips.com>
      Reviewed-by: default avatarDouglas Anderson <dianders@chromium.org>
      Tested-by: default avatarDouglas Anderson <dianders@chromium.org>
      Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      134f1f60
    • Caesar Wang's avatar
      ARM: rockchip: fix the SMP code style · 7f0b61ad
      Caesar Wang authored
      Use the below scripts to check:
      scripts/checkpatch.pl -f --subject arch/arm/mach-rockchip/platsmp.c
      Signed-off-by: default avatarCaesar Wang <wxt@rock-chips.com>
      Reviewed-by: default avatarDouglas Anderson <dianders@chromium.org>
      Reviewed-by: default avatarKever Yang <kever.yang@rock-chips.com>
      Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      7f0b61ad
    • Caesar Wang's avatar
      ARM: rockchip: ensure CPU to enter WFI/WFE state · e306bc16
      Caesar Wang authored
      The patch can ensure that v7_exit_coherency_flush() in rockchip_cpu_die()
      executed in time.
      The mdelay(1) has enough time to fix the problem of CPU offlining.
      That's a workaround way in rockchip hotplug code,
      At least, we haven't a better way to solve it. Who know,
      that maybe fixed by chip (hardware) in the future.
      Signed-off-by: default avatarCaesar Wang <wxt@rock-chips.com>
      Reviewed-by: default avatarDouglas Anderson <dianders@chromium.org>
      Reviewed-by: default avatarKever Yang <kever.yang@rock-chips.com>
      Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      e306bc16
    • Caesar Wang's avatar
      ARM: rockchip: fix the CPU soft reset · fe4407c0
      Caesar Wang authored
      We need different orderings when turning a core on and turning a core
      off.  In one case we need to assert reset before turning power off.
      In ther other case we need to turn power on and the deassert reset.
      
      In general, the correct flow is:
      
      CPU off:
          reset_control_assert
          regmap_update_bits(pmu, PMU_PWRDN_CON, BIT(pd), BIT(pd))
          wait_for_power_domain_to_turn_off
      CPU on:
          regmap_update_bits(pmu, PMU_PWRDN_CON, BIT(pd), 0)
          wait_for_power_domain_to_turn_on
          reset_control_deassert
      
      This is needed for stressing CPU up/down, as per:
          cd /sys/devices/system/cpu/
          for i in $(seq 10000); do
              echo "================= $i ============"
              for j in $(seq 100); do
                  while [[ "$(cat cpu1/online)$(cat cpu2/online)$(cat cpu3/online)" != "000"" ]]
                      echo 0 > cpu1/online
                      echo 0 > cpu2/online
                      echo 0 > cpu3/online
                  done
                  while [[ "$(cat cpu1/online)$(cat cpu2/online)$(cat cpu3/online)" != "111" ]]; do
                      echo 1 > cpu1/online
                      echo 1 > cpu2/online
                      echo 1 > cpu3/online
                  done
              done
          done
      
      The following is reproducable log:
          [34466.186812] PM: noirq suspend of devices complete after 0.669 msecs
          [34466.186824] Disabling non-boot CPUs ...
          [34466.187509] CPU1: shutdown
          [34466.188672] CPU2: shutdown
          [34473.736627] Kernel panic - not syncing:Watchdog detected hard LOCKUP on cpu 0
          .......
      or others similar log:
          .......
          [ 4072.454453] CPU1: shutdown
          [ 4072.504436] CPU2: shutdown
          [ 4072.554426] CPU3: shutdown
          [ 4072.577827] CPU1: Booted secondary processor
          [ 4072.582611] CPU2: Booted secondary processor
          <hang>
      
          Tested by cpu up/down scripts, the results told us need delay more time
      before write the sram. The wait time is affected by many aspects
      (e.g: cpu frequency, bootrom frequency, sram frequency, bus speed, ...).
      
          Although the cpus other than cpu0 will write the sram, the speedy is
      no the same as cpu0, if the cpu0 early wake up, perhaps the other cpus
      can't startup. As we know, the cpu0 can wake up when the cpu1/2/3 write
      the 'sram+4/8' and send the sev.
          Anyway.....
          At the moment, 1ms delay will be happy work for cpu up/down scripts test.
      Signed-off-by: default avatarCaesar Wang <wxt@rock-chips.com>
      Reviewed-by: default avatarDoug Anderson <dianders@chromium.org>
      Reviewed-by: default avatarKever Yang <kever.yang@rock-chips.com>
      Fixes: 3ee851e2 ("ARM: rockchip: add basic smp support for rk3288")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      fe4407c0
    • Doug Anderson's avatar
      ARM: rockchip: restore dapswjdp after suspend · 33939403
      Doug Anderson authored
      In the commit (0ea001d3 ARM: rockchip: disable dapswjdp during suspend)
      we made the assumption that we didn't need to restore dapswjdp after
      suspend because "the MASKROM will enable it back".
      
      It turns out that's not a safe assumption.  In some cases (pending
      interrupts) it's possible that the WFI might act as a no-op and the
      MaskROM will never run.  Since we're changing the bit, we should
      restore it ourselves.
      Signed-off-by: default avatarDoug Anderson <dianders@chromium.org>
      Reviewed-by: default avatarChris Zhong <zyw@rock-chips.com>
      Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      33939403
    • Linus Torvalds's avatar
      Linux 4.2-rc1 · d770e558
      Linus Torvalds authored
      d770e558
    • Linus Torvalds's avatar
      Merge tag 'platform-drivers-x86-v4.2-2' of... · a585d2b7
      Linus Torvalds authored
      Merge tag 'platform-drivers-x86-v4.2-2' of git://git.infradead.org/users/dvhart/linux-platform-drivers-x86
      
      Pull late x86 platform driver updates from Darren Hart:
       "The following came in a bit later and I wanted them to bake in next a
        few more days before submitting, thus the second pull.
      
        A new intel_pmc_ipc driver, a symmetrical allocation and free fix in
        dell-laptop, a couple minor fixes, and some updated documentation in
        the dell-laptop comments.
      
        intel_pmc_ipc:
         - Add Intel Apollo Lake PMC IPC driver
      
        tc1100-wmi:
         - Delete an unnecessary check before the function call "kfree"
      
        dell-laptop:
         - Fix allocating & freeing SMI buffer page
         - Show info about WiGig and UWB in debugfs
         - Update information about wireless control"
      
      * tag 'platform-drivers-x86-v4.2-2' of git://git.infradead.org/users/dvhart/linux-platform-drivers-x86:
        intel_pmc_ipc: Add Intel Apollo Lake PMC IPC driver
        tc1100-wmi: Delete an unnecessary check before the function call "kfree"
        dell-laptop: Fix allocating & freeing SMI buffer page
        dell-laptop: Show info about WiGig and UWB in debugfs
        dell-laptop: Update information about wireless control
      a585d2b7
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs · 1dc51b82
      Linus Torvalds authored
      Pull more vfs updates from Al Viro:
       "Assorted VFS fixes and related cleanups (IMO the most interesting in
        that part are f_path-related things and Eric's descriptor-related
        stuff).  UFS regression fixes (it got broken last cycle).  9P fixes.
        fs-cache series, DAX patches, Jan's file_remove_suid() work"
      
      [ I'd say this is much more than "fixes and related cleanups".  The
        file_table locking rule change by Eric Dumazet is a rather big and
        fundamental update even if the patch isn't huge.   - Linus ]
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (49 commits)
        9p: cope with bogus responses from server in p9_client_{read,write}
        p9_client_write(): avoid double p9_free_req()
        9p: forgetting to cancel request on interrupted zero-copy RPC
        dax: bdev_direct_access() may sleep
        block: Add support for DAX reads/writes to block devices
        dax: Use copy_from_iter_nocache
        dax: Add block size note to documentation
        fs/file.c: __fget() and dup2() atomicity rules
        fs/file.c: don't acquire files->file_lock in fd_install()
        fs:super:get_anon_bdev: fix race condition could cause dev exceed its upper limitation
        vfs: avoid creation of inode number 0 in get_next_ino
        namei: make set_root_rcu() return void
        make simple_positive() public
        ufs: use dir_pages instead of ufs_dir_pages()
        pagemap.h: move dir_pages() over there
        remove the pointless include of lglock.h
        fs: cleanup slight list_entry abuse
        xfs: Correctly lock inode when removing suid and file capabilities
        fs: Call security_ops->inode_killpriv on truncate
        fs: Provide function telling whether file_remove_privs() will do anything
        ...
      1dc51b82
    • Linus Torvalds's avatar
      bluetooth: fix list handling · 9b284cbd
      Linus Torvalds authored
      Commit 835a6a2f ("Bluetooth: Stop sabotaging list poisoning")
      thought that the code was sabotaging the list poisoning when NULL'ing
      out the list pointers and removed it.
      
      But what was going on was that the bluetooth code was using NULL
      pointers for the list as a way to mark it empty, and that commit just
      broke it (and replaced the test with NULL with a "list_empty()" test on
      a uninitialized list instead, breaking things even further).
      
      So fix it all up to use the regular and real list_empty() handling
      (which does not use NULL, but a pointer to itself), also making sure to
      initialize the list properly (the previous NULL case was initialized
      implicitly by the session being allocated with kzalloc())
      
      This is a combination of patches by Marcel Holtmann and Tedd Ho-Jeong
      An.
      
      [ I would normally expect to get this through the bt tree, but I'm going
        to release -rc1, so I'm just committing this directly   - Linus ]
      Reported-and-tested-by: default avatarJörg Otte <jrg.otte@gmail.com>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Original-by: default avatarTedd Ho-Jeong An <tedd.an@intel.com>
      Original-by: Marcel Holtmann <marcel@holtmann.org>:
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      9b284cbd
  4. 04 Jul, 2015 26 commits