SLIMBUS: m8 port, caf updates, new OC from poondog

Squashed commit of the following:

commit 539cf4405c91172a947bcc7a0e25c77388f82eb2
Author: poondog <markj338@gmail.com>
Date:   Sat Apr 26 12:53:32 2014 +1000

    DRIVERS: SLIMBUS: slimbus enhancements mkII

    This time we keep the root freq to 11.
    If Root Freq is set at 11, 24,576MHz has the best compatibility for all present sampling rates (e.g, any sample rate can be converted, 48KHz to 96KHz, 44.1KHz to 96KHz, 48KHz to 128KHz etc.) Increasing the root frequency is likely to cause invalid present sample rate combinations which leads to audio glitches such as distortion. "A Natural Frequency is defined as a CLK frequency that allows a family of data rates to be supported. The different sample rate flows can be optimally supported by changing a particular Natural Frequency using the Clock Gear." I looked at a Clock Gear/RF table and it looks like CLK Gear 10 and RF 24,576MHz (Stock RF) is an excellent combination due to its compatibility towards every other sample rates.

    ZeroInfinity/Poondog

    Signed-off-by: ZeroInfinity <infinitezero345@gmail.com>
    Signed-off-by: poondog <markj338@gmail.com>

commit 60abd0f38d3131f03c8d90ed597d38b72d6f6062
Author: Kiran Gunda <kgunda@codeaurora.org>
Date:   Mon Mar 17 16:11:40 2014 +0530

    Slim_ngd: Modify waiting mechanism in kthread

    wait_for_completion_timeout() is not a good option in
    kthread as it leads to scheduling the kthread on the every timeout.
    Hence modify it to wait_for_completion() from
    wait_for_completion_timeout().

    Signed-off-by: Kiran Gunda <kgunda@codeaurora.org>
    Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
    Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
    Signed-off-by: poondog <markj338@gmail.com>

commit 8c7210e51f62875740a6644d94420351e3827700
Author: Sagar Dharia <sdharia@codeaurora.org>
Date:   Fri Feb 7 19:40:12 2014 -0700

    slimbus: Use physical address type where physical address is used

    Use physical address type for buffers using physical address.
    (e.g. interaction with data-mover engine)

    Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
    Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
    Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
    Signed-off-by: poondog <markj338@gmail.com>

commit e59f4663f14a532d23f185270a1f6b70bdd87ee9
Author: Sagar Dharia <sdharia@codeaurora.org>
Date:   Mon Jan 27 20:55:59 2014 -0700

    slimbus: Enable clients to send user messages to devices.

    Slimbus protocol allows user messages of destination referred, or
    source referred type to be sent to a slimbus device.
    Provide framework to support such messages. Note that, controller
    may not support all user messages.

    Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
    Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
    Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
    Signed-off-by: poondog <markj338@gmail.com>

commit b215fa802827b7d92ad382a46343a0f064429e3d
Author: Sagar Dharia <sdharia@codeaurora.org>
Date:   Mon Feb 3 12:17:04 2014 -0700

    slim_ngd: Handle error flags before handling SENT flag

    It's possible that error flags were set alongwith SENT flag for
    TX transaction status. In such a scenario, error flag status should
    be handled (and SENT flag should be cleared). Move error-flag
    handling ahead of SENT flag handling to avoid interrupt being called
    twice, and completion being set twice.

    Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
    Signed-off-by: Kiran Gunda <kgunda@codeaurora.org>
    Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
    Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
    Signed-off-by: poondog <markj338@gmail.com>

commit 7c965751227983de551115652f29a550582ffa0c
Author: Kiran Gunda <kgunda@codeaurora.org>
Date:   Tue Oct 8 16:32:13 2013 +0530

    Slimbus: Correct the conditional check during channel removal

    Use actual channel number to check if the channel to be
    removed is present in the define_chan list before removing
    it, instead of using the internal channel number used by
    the frame work.

    Signed-off-by: Kiran Gunda <kgunda@codeaurora.org>
    Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
    Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
    Signed-off-by: poondog <markj338@gmail.com>

commit 6fe1b5e1261cc3a4589010d5c1475f3c1afa67ab
Author: Sagar Dharia <sdharia@codeaurora.org>
Date:   Fri Jun 21 12:18:20 2013 -0600

    slim_msm: Get platform-specific information from platform-data

    Number of pipes available to application processor for data channels,
    and product-code field of enumeration address needed for setting
    these pipes can be different for different platforms.
    Store this platform-specific information in platform-data, and get
    it from Device-Tree if applicable.

    Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
    Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
    Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
    Signed-off-by: poondog <markj338@gmail.com>

commit 57d703f4f2c93acfb3334c086db5f457ca25fce8
Author: Sagar Dharia <sdharia@codeaurora.org>
Date:   Wed May 15 20:18:01 2013 -0600

    slim_msm: Signal client's completion for per transfer notification

    Slimbus ports are connected to BAM pipes and ports inform the pipe
    when descriptor's data transfer is done. Clients queue a completion
    per descrptor when that descriptor is processed. This completion will
    get overwritten if client queues multiple descriptors. Use
    per-transfer user-data as client's completion to avoid this problem.
    This also reduces controller-driver involvement in data transfer.

    Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
    Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
    Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
    Signed-off-by: poondog <markj338@gmail.com>

commit c5dcdd6e481e62472fcc38581547e7b8b5ec0de7
Author: Sagar Dharia <sdharia@codeaurora.org>
Date:   Wed May 15 20:01:45 2013 -0600

    slim_msm: Report flow-error and mask apps slimbus port interrupts

    Apps side slimbus ports may overflow/underflow if BAM pipes connected
    to those ports don't have descriptors scheduled.
    Report such errors and mask the port interrupts until BAM pipes have
    descriptors scheduled to avoid interrupts firing multiple times.

    Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
    Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
    Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
    Signed-off-by: poondog <markj338@gmail.com>

commit 5e0ef9e3d423c4912b30096b5adfde785b9793bb
Author: Kiran Gunda <kgunda@codeaurora.org>
Date:   Mon Oct 21 17:00:15 2013 +0530

    slim_ngd: Add NULL pointer check apart from error check

    Check against NULL pointer after allocating
    the memory for msm_slim_ctrl structure pointer
    dynamically to avoid unexpected crashes.

    Earlier this pointer is checked only for error
    codes. In this patch NULL pointer check is also
    added.

    Signed-off-by: Kiran Gunda <kgunda@codeaurora.org>
    Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
    Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
    Signed-off-by: poondog <markj338@gmail.com>

commit 807c7164ceb461e21a46161f8706d81006fd2aa5
Author: Kiran Gunda <kgunda@codeaurora.org>
Date:   Tue Feb 4 07:45:03 2014 +0530

    slim-ngd: NULL pointer check for client buffer

    There is the chance of passing NULL pointer by the client
    during the Slimbus/Codec transactions. Hence add NULL
    pointer check for client buffer aswell.

    CRs-Fixed: 608324
    Change-Id: I161e8f04401afebb64ed72d5f392a67feb6ec13a
    Signed-off-by: Kiran Gunda <kgunda@codeaurora.org>
    Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
    Signed-off-by: poondog <markj338@gmail.com>

commit 85b21f63bfabb77732dc972e4132b6a9569ec9de
Author: Ajay Dudani <adudani@codeaurora.org>
Date:   Wed Aug 14 23:32:30 2013 -0700

    slim_ngd: Make sure transaction is not dereferenced after it's freed

    Every read transaction over slimbus is a set of one transmit and one
    receive. Receive part frees meta-data for the read transaction since
    it is no longer needed, and the transaction-ID can be reused.
    Make sure that the transmit function doesn't try to dereference the
    transaction meta-data after possibly receiving a response.

    CRs-fixed: 515802
    Change-Id: Id736ad368d4944a6aabc89f4ff295d664bc5efa0
    Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
    Signed-off-by: Ajay Dudani <adudani@codeaurora.org>

commit 5cf37798e4eef79f09f11325a1d9fadd20651333
Author: Sagar Dharia <sdharia@codeaurora.org>
Date:   Fri Apr 26 18:05:37 2013 -0600

    slim_ngd: Support reserving message bandwidth for clients

    Message bandwidth can be reserved by clients to do message-intensive
    transactions over Slimbus. While slimbus framework supports that,
    NGD driver was missing corresponding code to send this request to
    master driver on ADSP. This patch adds that support.

    Change-Id: If6a340746816658ac0aa1b4bd7c2270205eb6d4a
    Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>

commit 10c76ce03102e4ae76d090e4f3c7096d6b84a845
Author: Sagar Dharia <sdharia@codeaurora.org>
Date:   Fri Feb 22 19:06:39 2013 -0700

    slimbus: Handle channel control correctly if controller manages BW

    If bandwidth allocation is managed by controller (and not framework),
    channel control commands from all clients should be sent to the
    controller.

    Change-Id: Ibdd27c35a48818efdd55a0a84c52fbb9671cdb77
    Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>

commit 6d6927666e8d92156543053293a508f815c1565f
Author: Kiran Gunda <kgunda@codeaurora.org>
Date:   Thu Jan 10 17:03:33 2013 +0530

    slim_msm: Reading the smaller length messages properly

    If the smaller length messages(<= 4 Bytes) like REPORT_ABSENT
    are received over slimbus, the master driver is reading the
    excessive length than required. Due to that the next messages
    over slimbus are getting corrupted. This patch fixes this issue
    and also handles the REPORT_ABSENT message sent by the third party
    slimbus client devices.

    CRs-Fixed: 431529
    Change-Id: I7b3c07a94603482a6a9a7645ade70228144703bc
    Signed-off-by: Kiran Gunda <kgunda@codeaurora.org>

commit aa9c94d15b8d40c54e8a45f48e05495fe91b4cc2
Author: Sagar Dharia <sdharia@codeaurora.org>
Date:   Tue Jan 22 17:51:41 2013 -0700

    slimbus: Add slimbus device driver unregistration function

    slim_driver_unregister is added to reverse effects of
    slim_driver_register. That way a slimbus device driver can be
    registered when driver module is loaded, and unregistered when
    the driver module is unloaded.

    CRs-Fixed: 441540
    Change-Id: Iae64f84c99d5027c9b55c3fde5fe71c6a550354e
    Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>

    Conflicts:
    	include/linux/slimbus/slimbus.h

commit aedb21330278ef8a5a2050b211a6ea2ec9703033
Author: Sagar Dharia <sdharia@codeaurora.org>
Date:   Sat Dec 1 15:43:01 2012 -0700

    slimbus: Refine scope of controller and scheduler mutex locks

    Controller mutex scope is restricted to controller specific data
    structures, such as addressing table, transaction table.
    Scheduler lock is used to protect scheduling data structures (such
    as channels, and bandwidth).
    This way, controller mutex is not needed when expensive
    reconfiguration sequence(used for channel scheduling, bandwidth
    management) is in progress. Transactions over messaging channel (such
    as element read/writes, logical address assignment) can happen in
    parallel and don't have to block on reconfiguration sequence which
    only affects data channels.

    CRs-Fixed: 426945
    Change-Id: I2ca20aa76901ee19dba62874c86c2108fac9fa02
    Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>

commit dd94f94fd8d6d28c8b43435ad923b608c811678c
Author: Sagar Dharia <sdharia@codeaurora.org>
Date:   Tue Oct 30 13:44:08 2012 -0600

    slim_ngd: Rectify define, removal messages per protocol

    Populate required bits only as client handle while sending
    channel define, removal messages to the master driver.
    Previously, complete logical address was set as client handle
    which would corrupt other fields in that byte if logical
    address had non-zero MSBs. This patch fixes that problem.

    Change-Id: I96e8a7917c1fe68e1c86f6837c0b9f8ee187ca3d
    Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>

commit 96e8b46485257231829079bed73ebe42487cbab9
Author: Sagar Dharia <sdharia@codeaurora.org>
Date:   Tue Oct 30 21:12:09 2012 -0600

    slimbus: Populate slimbus device's logical address during assignment

    Slimbus device is assigned logical address when it reports present.
    Make sure to populate the device's logical address (laddr) during
    this assignment.

    CRs-Fixed: 412148
    Change-Id: Icb8d74f6ea71aff8f6cb30523002f7839e2cb028
    Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>

commit c66927d43475e8913c77dbc02c8eabd1cc146c0b
Author: Sagar Dharia <sdharia@codeaurora.org>
Date:   Wed Oct 17 22:41:57 2012 -0600

    slimbus: Specify number of channels for the group in group handle

    Use group handle instead of next element in channel's data structure
    to identify how many channels were specified by a client in the group.
    That way clients can specify different number of channels for shared
    channels, and work with their own client-handle. Note that sequence of
    channel still matters (so 2 clients sharing a channel should not
    specify channels in different order, otherwise scheduling of the
    channels will not be in the correct order)

    CRs-Fixed: 415109
    Change-Id: Idd636a500ee6449b16648a234b9e76fad21f2fcc
    Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>

commit f259ddaaf2957e127182fa25fce6b1f308d5beb3
Author: Stephen Boyd <sboyd@codeaurora.org>
Date:   Wed Oct 31 17:41:43 2012 -0700

    slim_msm: Fix unsafe locking in msm_sat_enqueue()

    msm_sat_enqueue() calls spin_lock() and msm_sat_dequeue() calls
    spin_lock_irqsave(). This leads to lockdep warnings about the
    same lock being taken in interrupts on and interrupts off context
    which can lead to a potential deadlock.

    =================================
    [ INFO: inconsistent lock state ]
    3.4.0+ #382 Tainted: G        W
    ---------------------------------
    inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
    kworker/u:2/94 [HC1[1]:SC0[0]:HE0:SE1] takes:
     (&(&sat->lock)->rlock){?.+...}, at: [<c0348b80>] msm_sat_enqueue+0x20/0xb0
    {HARDIRQ-ON-W} state was registered at:
      [<c00bd290>] __lock_acquire+0x664/0x8d8
      [<c00bd690>] lock_acquire+0x18c/0x1e8
      [<c06989a4>] _raw_spin_lock+0x38/0x48
      [<c0348b80>] msm_sat_enqueue+0x20/0xb0
      [<c0349338>] msm_slim_rxwq+0x278/0x42c
      [<c0349580>] msm_slim_rx_msgq_thread+0x94/0x1f8
      [<c008e480>] kthread+0x90/0xa0
      [<c000f438>] kernel_thread_exit+0x0/0x8
    irq event stamp: 24219
    hardirqs last  enabled at (24218): [<c0699188>] _raw_spin_unlock_irqrestore+0x3c/0x68
    hardirqs last disabled at (24219): [<c06993f4>] __irq_svc+0x34/0x78
    softirqs last  enabled at (24129): [<c00738a8>] irq_exit+0x54/0xa8
    softirqs last disabled at (24108): [<c00738a8>] irq_exit+0x54/0xa8

    other info that might help us debug this:
     Possible unsafe locking scenario:

           CPU0
           ----
      lock(&(&sat->lock)->rlock);
      <Interrupt>
        lock(&(&sat->lock)->rlock);

     *** DEADLOCK ***

    3 locks held by kworker/u:2/94:
     #0:  ((sat->satcl.name)){.+.+.+}, at: [<c0087124>] process_one_work+0x1e8/0x648
     #1:  ((&sat->wd)){+.+.+.}, at: [<c0087124>] process_one_work+0x1e8/0x648
     #2:  (&dev->tx_lock){+.+...}, at: [<c0349cac>] msm_xfer_msg+0xb4/0x51c

    stack backtrace:
    [<c00151b0>] (unwind_backtrace+0x0/0x120) from [<c00b9d48>] (print_usage_bug+0x258/0x2c0)
    [<c00b9d48>] (print_usage_bug+0x258/0x2c0) from [<c00ba12c>] (mark_lock+0x37c/0x68c)
    [<c00ba12c>] (mark_lock+0x37c/0x68c) from [<c00bd20c>] (__lock_acquire+0x5e0/0x8d8)
    [<c00bd20c>] (__lock_acquire+0x5e0/0x8d8) from [<c00bd690>] (lock_acquire+0x18c/0x1e8)
    [<c00bd690>] (lock_acquire+0x18c/0x1e8) from [<c06989a4>] (_raw_spin_lock+0x38/0x48)
    [<c06989a4>] (_raw_spin_lock+0x38/0x48) from [<c0348b80>] (msm_sat_enqueue+0x20/0xb0)
    [<c0348b80>] (msm_sat_enqueue+0x20/0xb0) from [<c0348dc8>] (msm_slim_interrupt+0x1b8/0x4b0)
    [<c0348dc8>] (msm_slim_interrupt+0x1b8/0x4b0) from [<c00d2ccc>] (handle_irq_event_percpu+0x118/0x3a4)
    [<c00d2ccc>] (handle_irq_event_percpu+0x118/0x3a4) from [<c00d2f94>] (handle_irq_event+0x3c/0x5c)
    [<c00d2f94>] (handle_irq_event+0x3c/0x5c) from [<c00d5c4c>] (handle_fasteoi_irq+0xd0/0x11c)
    [<c00d5c4c>] (handle_fasteoi_irq+0xd0/0x11c) from [<c00d2ae4>] (generic_handle_irq+0x24/0x2c)
    [<c00d2ae4>] (generic_handle_irq+0x24/0x2c) from [<c000f370>] (handle_IRQ+0x7c/0xc0)
    [<c000f370>] (handle_IRQ+0x7c/0xc0) from [<c0008774>] (gic_handle_irq+0x6c/0xc4)
    [<c0008774>] (gic_handle_irq+0x6c/0xc4) from [<c0699404>] (__irq_svc+0x44/0x78)
    Exception stack(0xee061cd8 to 0xee061d20)
    1cc0:                                                       00000001 eebda7c8
    1ce0: 00000000 eebda400 20000013 c12b5430 ec96c168 c12b542c c12b5430 00000001
    1d00: 20000013 ee061e14 3eb13eb1 ee061d20 c00ba520 c069918c 20000013 ffffffff
    [<c0699404>] (__irq_svc+0x44/0x78) from [<c069918c>] (_raw_spin_unlock_irqrestore+0x40/0x68)
    [<c069918c>] (_raw_spin_unlock_irqrestore+0x40/0x68) from [<c0279f2c>] (__debug_object_init+0x30c/0x344)
    [<c0279f2c>] (__debug_object_init+0x30c/0x344) from [<c007b068>] (init_timer_on_stack_key+0x18/0x30)
    [<c007b068>] (init_timer_on_stack_key+0x18/0x30) from [<c0695248>] (schedule_timeout+0x8c/0x4c0)
    [<c0695248>] (schedule_timeout+0x8c/0x4c0) from [<c069768c>] (wait_for_common+0xec/0x164)
    [<c069768c>] (wait_for_common+0xec/0x164) from [<c0349fc4>] (msm_xfer_msg+0x3cc/0x51c)
    [<c0349fc4>] (msm_xfer_msg+0x3cc/0x51c) from [<c034a358>] (slim_sat_rxprocess+0x244/0x664)
    [<c034a358>] (slim_sat_rxprocess+0x244/0x664) from [<c0087290>] (process_one_work+0x354/0x648)
    [<c0087290>] (process_one_work+0x354/0x648) from [<c0089754>] (worker_thread+0x1a8/0x2a8)
    [<c0089754>] (worker_thread+0x1a8/0x2a8) from [<c008e480>] (kthread+0x90/0xa0)
    [<c008e480>] (kthread+0x90/0xa0) from [<c000f438>] (kernel_thread_exit+0x0/0x8)

    Make this lock irqsafe as well so that this potential bug doesn't
    occur.

    Change-Id: Icbef6d1d749ee6ee81b079e19e57f22c38f00c68
    Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>

commit 62d507f313d6921b1e0aea1e80208814f67317a7
Author: poondog <markj338@gmail.com>
Date:   Tue Apr 22 13:06:16 2014 +1000

    slimbus: remove this too

    Signed-off-by: poondog <markj338@gmail.com>

commit 585e5b930ba1dcaeb6c6fe92638e7b3e6ba8ad22
Author: poondog <markj338@gmail.com>
Date:   Tue Apr 22 12:59:04 2014 +1000

    slilmbus: remove some functions that are incompatible with the current setup
    we do not have the same qdsp6v2 files as the hammerhead so this will not work

    Signed-off-by: poondog <markj338@gmail.com>

commit 56ba16baf80a7a2acf99bac8f1f5b08890922aa7
Author: Sagar Dharia <sdharia@codeaurora.org>
Date:   Wed Sep 12 23:21:57 2012 -0600

    slim_ngd: Slimbus satellite controller driver

    NGD (non-ported generic device, also known as satellite device) is
    used to implement light-weight slimbus controller driver.
    This driver is responsible for:
    1. Communicating with codec (or any slimbus slave registered from
    application processor side) directly using slimbus HW messaging
    interface.
    2. Communicating with the manager device (controller by master driver)
    on LPASS to do bandwidth and data channel management. NGD takes these
    requests from slimbus slave on application processor side and passes
    them to the manager device using slimbus messaging itself.
    SPS BAM is used for receiving messages to offload CPU, and to enable
    receiving multiple messages before driver can process them.
    Runtime-pm is used for power management. Controller is in active
    power state when messaging and/or data-channels are active from
    application processor side.

    Change-Id: Iff53c0ca9b768a3dac3bccb5004fd2f96070af50
    Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>

commit 78925cab4b96dfd42f8f95d59dba59b51f15501b
Author: Kiran Gunda <kgunda@codeaurora.org>
Date:   Tue Oct 9 13:30:13 2012 +0530

    slimbus: Avoid same channel definition, removal in same sequence

    Do not add the channel removal request to the remove list
    when the client sends it right after the channel definition
    without sending reconfigure_now request. Also remove the
    channel define request from define list. This avoids
    channel definition count being inconsistent, which may
    lead to slimbus driver going into wrong state.

    CRs-fixed: 409161
    Change-Id: Iec4dd51d98416b7d769176bb1ef6cd2f5bacfa12
    Signed-off-by: Kiran Gunda <kgunda@codeaurora.org>

commit f5f0fa405d0cbabe2de7df147448bc0da4a03993
Author: Sagar Dharia <sdharia@codeaurora.org>
Date:   Wed Oct 17 12:42:03 2012 -0600

    slim_msm: Allow remote management of pipes for MSM slimbus BAM

    Slimbus BAM may not be locally owned and/or controlled. In that case,
    a remote processor (e.g. LPASS) configures BAM and sets security
    configurations for the BAM pipes.
    Allow driver to choose whether BAM is locally or remotely managed.

    Change-Id: I10741cb394428f525c1633e707e88e699aa63cf5
    Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>

commit 8cd00aa99ce508ea320d7c4b31ad837b943dbb64
Author: Sagar Dharia <sdharia@codeaurora.org>
Date:   Sun Sep 9 17:32:46 2012 -0600

    slimbus: Allow controller to specify logical addresses

    It is possible that the controller has fixed addressing table for
    enumeration devices. In that case, logical address will be set by
    controller and not by framework. get_laddr allows a controller to
    assign logical address. Make sure framework allows such addressing
    by not assuming that index into address table will represent logical
    address.

    Change-Id: I0e3873980c2ee2ece01237f450ecefff4e99aedc
    Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>

commit ef88b1aa410faffc434abd49292106644588df77
Author: Sagar Dharia <sdharia@codeaurora.org>
Date:   Tue Jul 24 23:44:26 2012 -0600

    slimbus: Allow controller to override default scheduling algorithm

    Framework provides a slimbus scheduling algorithm and controller may
    choose to override it. e.g. controller will override this if it
    supports fixed set of channels at a fixed clock gear.
    In that case, it is controller's responsibility to act on client
    requests and update channel scheduling, subframe coding information.

    Change-Id: I31fe72ef85f931900467b737652da7516d173dc5
    Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>

commit e0a22a6b22019297c50cf3e95d31eb54d369e214
Author: Sagar Dharia <sdharia@codeaurora.org>
Date:   Tue Aug 21 18:07:39 2012 -0600

    slim_msm: Move out common functionality from MSM controller driver

    Starting with new platforms, MSM slimbus controller can operate in
    master mode or satellite mode. (Not in both modes for the same build)
    Move out common functional code from the controller driver that can
    be reused by satellite mode and master mode.

    Change-Id: Idbc3fa93067f67f645981071ff6ad457c284576f
    Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>

commit 72d04b21a12c2bcaf86ae98e85244764aa3eadcf
Author: Sagar Dharia <sdharia@codeaurora.org>
Date:   Wed Sep 5 12:19:24 2012 -0600

    slim_msm: Satellite channel should not be deallocated more than once

    It is possible that satellite channel deallocation is requested more
    than once. (e.g. if the satellite times out waiting for response from
    previous removal, then it will request removal again during
    channel deallocation from its side).
    Make sure that does not result in deallocating the channel more than
    once.

    CRs-fixed: 395926
    Change-Id: I002635849bcaa7309de1fbddf1127c456bca6f20
    Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>

commit 16e06dfa6ece7238b9a95569e662fcad1b991fd9
Author: Sagar Dharia <sdharia@codeaurora.org>
Date:   Tue Sep 4 11:27:26 2012 -0600

    slim_msm: Retry initial sequence messages

    Initial sequence messages (logical address assignment, and master
    capability message) are very important messages to enable the
    devices. It is possible that the device may NACK these messages
    initially if it is in process of acquiring sync.
    If these type of messages fail, retry a few times before actually
    deeming the device unresponsive. Log the registers in case of NACKs
    to better analyze the reason.

    CRs-fixed: 396230
    Change-Id: If0824f7ba962dbce068756e810a7bad8342373ec
    Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>

commit 1b74f2066c48d4956a3b2ddaad47a6b2f22998f8
Author: Sagar Dharia <sdharia@codeaurora.org>
Date:   Tue Sep 4 19:56:18 2012 -0600

    slimbus: Clear slimbus read transaction if synchronous read fails

    Failed read transaction is removed from the table of active
    transactions if the transaction fails

    CRs-fixed: 396237
    Change-Id: Idda4d8b5fa2cdfde8a049cc4af4d92e9e57f678a
    Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>

commit 435a6a4b3a8e9c24234af14fc22c04f607ee3151
Author: Sagar Dharia <sdharia@codeaurora.org>
Date:   Thu Aug 16 16:43:58 2012 -0600

    slimbus: Decrement channel reference during reconfigure now

    Slimbus clients can specify multiple add/remove channel requests
    through control_ch API, followed by reconfiguration request (also
    known as "commit request"). Clients may rely on the reconfiguration
    request to actuate the channel activation/removal and not the
    control-channel API.
    So the channel reference should be decremented during reconfiguration
    request, and not control_ch API.

    CRs-Fixed: 389518
    Change-Id: Id6ff57c6a4cad878e35004937fb08daf3b9afe7b
    Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>

commit b205adc23e9737522fb52d7f67d95f90c0780681
Author: Sagar Dharia <sdharia@codeaurora.org>
Date:   Wed Aug 15 00:01:57 2012 -0600

    slim_msm: Keep track of satellite reconfiguring a channel

    With mutiple clients able to use the same channel, it is not correct
    assumption that a channel was active due to satellite client's
    reconfiguration only. So during sub-system restart of a satellite,
    rely on satellite-reconfiguration vote for a channel instead of
    channel status to remove channels that were setup by the satellite
    before sub-system restart.

    CRs-Fixed: 389514
    Change-Id: I825381f15cb55396fece5b390d395c7f0a7580ff
    Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>

commit 33376c0388358f440f2f92aaa1003c641a4ac086
Author: Joonwoo Park <joonwoop@codeaurora.org>
Date:   Tue Aug 28 15:26:11 2012 -0700

    slimbus: Defer probing slimbus until ADSP is ready

    If slimbus master resides in ADSP, slimbus driver has to wait until it's
    up and running.  Do probe deferral until ADSP is ready.

    Change-Id: I31ba4e270331c3b5250758f604d0d0cde9537427
    Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>

commit f9d4310b2eecd6cfc394675cf9e3297e08710f40
Author: Sagar Dharia <sdharia@codeaurora.org>
Date:   Tue Aug 28 12:20:49 2012 -0600

    slimbus: Add slave devices to controller after controller HW is up

    Register controller is only responsible for making sure slimbus
    controller structure is initialized with framework. This should not
    assume that slimbus controller's hardware programming is done (e.g. if
    slave's probe is trying to get logical address, then that will fail if
    controller is registered, but slimbus hardware programming is not
    complete, since probe is called synchrounously when device is added.
    So this API separates register controller from slave device
    registration. It should be called by controller when its hardware
    programming is complete.

    Change-Id: I52fa5567fc072951c89f99c70507aa3b1e4e22af
    Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>

commit 88716f3e25aa5c692a6402e9cf9e5b8c21112b83
Author: Sagar Dharia <sdharia@codeaurora.org>
Date:   Sat Aug 11 15:02:12 2012 -0600

    slim: msm: Control interface clock if it's specified

    Some platforms (e.g. 8974) have interface clock that is not ON by
    default. Turn it ON during probe, and control it like core clock
    if it needs to be controlled.

    Change-Id: Ifffb4b7ea9afb5f3f1208b4b2b6638594ffca541
    Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>

commit e11bed21cdb0cf8c7b1e93dc6dca5a8c57102c49
Author: Sagar Dharia <sdharia@codeaurora.org>
Date:   Mon Jul 23 19:38:57 2012 -0600

    slimbus: Callback to indicate device report present message

    Clients can register a callback (just like probe) and that callback
    will be called when the client's device reports present per slimbus
    specification. The callback is hosted in a workqueue to avoid doing
    it in same context from which probe is called (and/or in the context
    receiving report present message). Callback is called when the device
    reports present for the first time after the bus is initialized.

    Change-Id: I8396b87121950f99a09764d497bf2d4b1535565d
    Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>

commit bc30a59963e7e5890f6129a993c961d6c12e2cd1
Author: Sagar Dharia <sdharia@codeaurora.org>
Date:   Thu Jul 26 16:56:44 2012 -0600

    slimbus: Fix channel concurrent usage during reconfiguration sequence

    Reconfiguration sequence can lead to changes in channel segment
    distribution and state. Since multiple clients can use 1 channel,
    make sure channels cannot be manipulated when reconfiguration
    sequence is in progress, and make sure that client doesn't send
    reconfiguration sequence when no changes are pending to be sent
    in the sequence from it.

    CRs-Fixed: 383406
    Change-Id: Ib5f0bc32f67f51f118fa417a2e580c8dc87ef0d0
    Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>

commit 1dddb86909299d905a56a7dbd631112dd7a0af1d
Author: Sagar Dharia <sdharia@codeaurora.org>
Date:   Tue Jul 31 19:06:21 2012 -0600

    slim:msm: Change to register access for RX path if required

    MSM controller for slimbus usually uses a BAM pipe to receive control
    data. However, some targets may not have a BAM pipe assinged for
    receiving this data. In that case, RX data should be received using
    direct register access instead.
    Introduce a Device-Tree property to change this access.

    Change-Id: I9bb1502f25e0e855937bc6fb4131f55348d04794
    Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>

commit f4574818d4ce906544993fec33e97b48af1e4b61
Author: Sagar Dharia <sdharia@codeaurora.org>
Date:   Tue Jul 24 23:04:32 2012 -0600

    slimbus: Export clock pause function

    Previously this function was left-out to be exported by mistake.
    Exporting the function helps any caller driver to be a module.

    Change-Id: I2b9caca62821caea5ae92123689c6f8ddf2b207a
    Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>

commit 2523d1a8776fe815e209757a919d147dc519dfa4
Author: Sagar Dharia <sdharia@codeaurora.org>
Date:   Wed Jul 11 15:52:46 2012 -0600

    slimbus: Disconnect source port if source end is removed by client

    If source end of a channel removes its vote, it should be allowed to
    be reclaimed by other client (or by other source port by same client)
    who wants to be the source for this channel.

    CRs-Fixed: 376731
    Change-Id: Ia30c6a4b07de7df98cde8bc928205b4f4598036d
    Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>

commit a91f20ad4f0fa3c036799e6a9b1a9d73e6d1e413
Author: Sagar Dharia <sdharia@codeaurora.org>
Date:   Mon Jun 25 12:44:02 2012 -0600

    slimbus: Modify check for empty slots

    There was a corner case where the open slot count was going -ve
    indicating that there are no slots left for messaging. The current
    check to ensure non-zero messaging slots does not take that into
    account. This commit fixes that check.

    CRs-fixed: 370229
    Change-Id: I832ce0a26f1919d3d03b4ef0311603a5a778685e
    Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>

commit f7583a13f2195b1c38ae6254e0d147ae08d5cd80
Author: David Brown <davidb@codeaurora.org>
Date:   Thu Jan 17 16:46:16 2013 -0800

    slimbus: Add Qualcomm Slimbus driver

    Signed-off-by: David Brown <davidb@codeaurora.org>

commit e1907b8f4378fbfdc1c34635307f8226d8d8777c
Author: poondog <markj338@gmail.com>
Date:   Tue Apr 22 12:07:27 2014 +1000

    DRIVERS: SLIMBUS: removal of current slimbus drivers
    slimbus is overrated anyway, who needs it?

    Signed-off-by: poondog <markj338@gmail.com>

    Conflicts:
    	drivers/slimbus/slim-msm-ctrl.c
    	drivers/slimbus/slimbus.c
Revert "block, bfq: add Early Queue Merge (EQM) to BFQ-v7r2 for 3.4.0"

This reverts commit 64aff1a3de8b941235696b69d2b412dd21625a8a.
Revert "Update BFQ I/O scheduler to v7r2"

This reverts commit 3ad6edff8b54cc087560bd1092ff925e1e14ebfc.
block: introduce the BFQ-v7r3 I/O sched for 3.4

Add the BFQ-v7r3 I/O scheduler to 3.4.
The general structure is borrowed from CFQ, as much of the code for
handling I/O contexts. Over time, several useful features have been
ported from CFQ as well (details in the changelog in README.BFQ). A
(bfq_)queue is associated to each task doing I/O on a device, and each
time a scheduling decision has to be made a queue is selected and served
until it expires.

    - Slices are given in the service domain: tasks are assigned
      budgets, measured in number of sectors. Once got the disk, a task
      must however consume its assigned budget within a configurable
      maximum time (by default, the maximum possible value of the
      budgets is automatically computed to comply with this timeout).
      This allows the desired latency vs "throughput boosting" tradeoff
      to be set.

    - Budgets are scheduled according to a variant of WF2Q+, implemented
      using an augmented rb-tree to take eligibility into account while
      preserving an O(log N) overall complexity.

    - A low-latency tunable is provided; if enabled, both interactive
      and soft real-time applications are guaranteed a very low latency.

    - Latency guarantees are preserved also in the presence of NCQ.

    - Also with flash-based devices, a high throughput is achieved
      while still preserving latency guarantees.

    - BFQ features Early Queue Merge (EQM), a sort of fusion of the
      cooperating-queue-merging and the preemption mechanisms present
      in CFQ. EQM is in fact a unified mechanism that tries to get a
      sequential read pattern, and hence a high throughput, with any
      set of processes performing interleaved I/O over a contiguous
      sequence of sectors.

    - BFQ supports full hierarchical scheduling, exporting a cgroups
      interface.  Since each node has a full scheduler, each group can
      be assigned its own weight.

    - If the cgroups interface is not used, only I/O priorities can be
      assigned to processes, with ioprio values mapped to weights
      with the relation weight = IOPRIO_BE_NR - ioprio.

    - ioprio classes are served in strict priority order, i.e., lower
      priority queues are not served as long as there are higher
      priority queues.  Among queues in the same class the bandwidth is
      distributed in proportion to the weight of each queue. A very
      thin extra bandwidth is however guaranteed to the Idle class, to
      prevent it from starving.

Signed-off-by: Paolo Valente <paolo.valente@unimore.it>
Signed-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>
Signed-off-by: poondog <markj338@gmail.com>

Conflicts:
	block/bfq-cgroup.c
	block/bfq-ioc.c
	block/bfq-iosched.c
	block/bfq-sched.c
	block/bfq.h
	include/linux/cgroup_subsys.h
block, bfq: add Early Queue Merge (EQM) to BFQ-v7r3 for 3.4.0

A set of processes may happen  to  perform interleaved reads, i.e., requests
whose union would give rise to a  sequential read  pattern.  There are two
typical  cases: in the first  case,   processes  read  fixed-size chunks of
data at a fixed distance from each other, while in the second case processes
may read variable-size chunks at  variable distances. The latter case occurs
for  example with  KVM, which  splits the  I/O generated  by the  guest into
multiple chunks,  and lets these chunks  be served by a  pool of cooperating
processes,  iteratively  assigning  the  next  chunk of  I/O  to  the first
available  process. CFQ  uses actual  queue merging  for the  first type of
rocesses, whereas it  uses preemption to get a sequential  read pattern out
of the read requests  performed by the second type of  processes. In the end
it uses  two different  mechanisms to  achieve the  same goal: boosting the
throughput with interleaved I/O.

This patch introduces  Early Queue Merge (EQM), a unified mechanism to get a
sequential  read pattern  with both  types of  processes. The  main idea is
checking newly arrived requests against the next request of the active queue
both in case of actual request insert and in case of request merge. By doing
so, both the types of processes can be handled by just merging their queues.
EQM is  then simpler and  more compact than the  pair of mechanisms used in
CFQ.

Finally, EQM  also preserves the  typical low-latency properties of BFQ, by
properly restoring the weight-raising state of  a queue when it gets back to
a non-merged state.

Signed-off-by: Mauro Andreolini <mauro.andreolini@unimore.it>
Signed-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>
Reviewed-by: Paolo Valente <paolo.valente@unimore.it>
Signed-off-by: poondog <markj338@gmail.com>
use Linaro 4.9.1

Conflicts:
	jamiethemorris-build-config
fix 4.9.1 build error
Revert "enable mach memutils in defconfig"

This reverts commit 56a57791efbbe1c5ea6041bd8247b8d82a2259fd.
fix version derp
disable intelliplug
mm: oom: squashed oom updates

Conflicts:
	include/linux/memcontrol.h
	mm/oom_kill.c
mm: oom: squashed oom commits round2

combined the following:

mm, oom: allow exiting threads to have access to memory reserves
Exiting threads, those with PF_EXITING set, can pagefault and require
memory before they can make forward progress.  This happens, for instance,
when a process must fault task->robust_list, a userspace structure, before
detaching its memory.

These threads also aren't guaranteed to get access to memory reserves
unless oom killed or killed from userspace.  The oom killer won't grant
memory reserves if other threads are also exiting other than current and
stalling at the same point.  This prevents needlessly killing processes
when others are already exiting.

Instead of special casing all the possible situations between PF_EXITING
getting set and a thread detaching its mm where it may allocate memory,
which probably wouldn't get updated when a change is made to the exit
path, the solution is to give all exiting threads access to memory
reserves if they call the oom killer.  This allows them to quickly
allocate, detach its mm, and free the memory it represents.

Summary of Luigi's bug report:

: He had an oom condition where threads were faulting on task->robust_list
: and repeatedly called the oom killer but it would defer killing a thread
: because it saw other PF_EXITING threads.  This can happen anytime we need
: to allocate memory after setting PF_EXITING and before detaching our mm;
: if there are other threads in the same state then the oom killer won't do
: anything unless one of them happens to be killed from userspace.
:
: So instead of only deferring for PF_EXITING and !task->robust_list, it's
: better to just give them access to memory reserves to prevent a potential
: livelock so that any other faults that may be introduced in the future in
: the exit path don't cause the same problem (and hopefully we don't allow
: too many of those!).

Signed-off-by: David Rientjes <rientjes@google.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Tested-by: Luigi Semenzato <semenzato@google.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

oom: use N_MEMORY instead N_HIGH_MEMORY
N_HIGH_MEMORY stands for the nodes that has normal or high memory.
N_MEMORY stands for the nodes that has any memory.

The code here need to handle with the nodes which have memory, we should
use N_MEMORY instead.

Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Acked-by: Hillf Danton <dhillf@gmail.com>
Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Lin Feng <linfeng@cn.fujitsu.com>
Cc: David Rientjes <rientjes@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm, oom: remove redundant sleep in pagefault oom handler
out_of_memory() will already cause current to schedule if it has not been
killed, so doing it again in pagefault_out_of_memory() is redundant.
Remove it.

Signed-off-by: David Rientjes <rientjes@google.com>
Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Reviewed-by: Michal Hocko <mhocko@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

oom_kill: change oom_kill.c to use for_each_thread()
Change oom_kill.c to use for_each_thread() rather than the racy
while_each_thread() which can loop forever if we race with exit.

Note also that most users were buggy even if while_each_thread() was
fine, the task can exit even _before_ rcu_read_lock().

Fortunately the new for_each_thread() only requires the stable
task_struct, so this change fixes both problems.

Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Reviewed-by: Sergey Dyasly <dserrg@gmail.com>
Tested-by: Sergey Dyasly <dserrg@gmail.com>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Mandeep Singh Baines <msb@chromium.org>
Cc: "Ma, Xindong" <xindong.ma@intel.com>
Reviewed-by: Michal Hocko <mhocko@suse.cz>
Cc: "Tu, Xiaobing" <xiaobing.tu@intel.com>
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

oom_kill: has_intersects_mems_allowed() needs rcu_read_lock()
At least out_of_memory() calls has_intersects_mems_allowed() without
even rcu_read_lock(), this is obviously buggy.

Add the necessary rcu_read_lock().  This means that we can not simply
return from the loop, we need "bool ret" and "break".

While at it, swap the names of task_struct's (the argument and the
local).  This cleans up the code a little bit and avoids the unnecessary
initialization.

Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Reviewed-by: Sergey Dyasly <dserrg@gmail.com>
Tested-by: Sergey Dyasly <dserrg@gmail.com>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Mandeep Singh Baines <msb@chromium.org>
Cc: "Ma, Xindong" <xindong.ma@intel.com>
Reviewed-by: Michal Hocko <mhocko@suse.cz>
Cc: "Tu, Xiaobing" <xiaobing.tu@intel.com>
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

oom_kill: add rcu_read_lock() into find_lock_task_mm()
find_lock_task_mm() expects it is called under rcu or tasklist lock, but
it seems that at least oom_unkillable_task()->task_in_mem_cgroup() and
mem_cgroup_out_of_memory()->oom_badness() can call it lockless.

Perhaps we could fix the callers, but this patch simply adds rcu lock
into find_lock_task_mm().  This also allows to simplify a bit one of its
callers, oom_kill_process().

Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Cc: Sergey Dyasly <dserrg@gmail.com>
Cc: Sameer Nanda <snanda@chromium.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Mandeep Singh Baines <msb@chromium.org>
Cc: "Ma, Xindong" <xindong.ma@intel.com>
Reviewed-by: Michal Hocko <mhocko@suse.cz>
Cc: "Tu, Xiaobing" <xiaobing.tu@intel.com>
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm, oom: prefer thread group leaders for display purposes
When two threads have the same badness score, it's preferable to kill
the thread group leader so that the actual process name is printed to
the kernel log rather than the thread group name which may be shared
amongst several processes.

This was the behavior when select_bad_process() used to do
for_each_process(), but it now iterates threads instead and leads to
ambiguity.

Signed-off-by: David Rientjes <rientjes@google.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Greg Thelen <gthelen@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm, oom: base root bonus on current usage
A 3% of system memory bonus is sometimes too excessive in comparison to
other processes.

With commit a63d83f ("oom: badness heuristic rewrite"), the OOM
killer tries to avoid killing privileged tasks by subtracting 3% of
overall memory (system or cgroup) from their per-task consumption.  But
as a result, all root tasks that consume less than 3% of overall memory
are considered equal, and so it only takes 33+ privileged tasks pushing
the system out of memory for the OOM killer to do something stupid and
kill dhclient or other root-owned processes.  For example, on a 32G
machine it can't tell the difference between the 1M agetty and the 10G
fork bomb member.

The changelog describes this 3% boost as the equivalent to the global
overcommit limit being 3% higher for privileged tasks, but this is not
the same as discounting 3% of overall memory from _every privileged task
individually_ during OOM selection.

Replace the 3% of system memory bonus with a 3% of current memory usage
bonus.

By giving root tasks a bonus that is proportional to their actual size,
they remain comparable even when relatively small.  In the example
above, the OOM killer will discount the 1M agetty's 256 badness points
down to 179, and the 10G fork bomb's 262144 points down to 183500 points
and make the right choice, instead of discounting both to 0 and killing
agetty because it's first in the task list.

Signed-off-by: David Rientjes <rientjes@google.com>
Reported-by: Johannes Weiner <hannes@cmpxchg.org>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

introduce for_each_thread() to replace the buggy while_each_thread()
while_each_thread() and next_thread() should die, almost every lockless
usage is wrong.

1. Unless g == current, the lockless while_each_thread() is not safe.

   while_each_thread(g, t) can loop forever if g exits, next_thread()
   can't reach the unhashed thread in this case. Note that this can
   happen even if g is the group leader, it can exec.

2. Even if while_each_thread() itself was correct, people often use
   it wrongly.

   It was never safe to just take rcu_read_lock() and loop unless
   you verify that pid_alive(g) == T, even the first next_thread()
   can point to the already freed/reused memory.

This patch adds signal_struct->thread_head and task->thread_node to
create the normal rcu-safe list with the stable head.  The new
for_each_thread(g, t) helper is always safe under rcu_read_lock() as
long as this task_struct can't go away.

Note: of course it is ugly to have both task_struct->thread_node and the
old task_struct->thread_group, we will kill it later, after we change
the users of while_each_thread() to use for_each_thread().

Perhaps we can kill it even before we convert all users, we can
reimplement next_thread(t) using the new thread_head/thread_node.  But
we can't do this right now because this will lead to subtle behavioural
changes.  For example, do/while_each_thread() always sees at least one
task, while for_each_thread() can do nothing if the whole thread group
has died.  Or thread_group_empty(), currently its semantics is not clear
unless thread_group_leader(p) and we need to audit the callers before we
can change it.

So this patch adds the new interface which has to coexist with the old
one for some time, hopefully the next changes will be more or less
straightforward and the old one will go away soon.

Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Reviewed-by: Sergey Dyasly <dserrg@gmail.com>
Tested-by: Sergey Dyasly <dserrg@gmail.com>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Acked-by: David Rientjes <rientjes@google.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Mandeep Singh Baines <msb@chromium.org>
Cc: "Ma, Xindong" <xindong.ma@intel.com>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: "Tu, Xiaobing" <xiaobing.tu@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Paul Reioux <reioux@gmail.com>

lowmemorykiller.c: convert to use for_each_thread
Signed-off-by: Paul Reioux <reioux@gmail.com>
reduce memory usage by input driver

input: evdev: daisy-chain header and client buffers

The evdev driver calculates memory required to hold
client data using power-of-2 math, and then adds header
size, which pushes the request over the power of 2 and
requires 2x larger allocation.

Change the logic to daisy-chain the header and client array.
That way instead of single order4 allocation, we will make
order0+order2.

Change-Id: Ibebfcce40b56a0b9b8c98b2700fa99e5f4976e2e
Signed-off-by: Igor Kovalenko <cik009@motorola.com>
Reviewed-on: http://gerrit.pcs.mot.com/533666
SLT-Approved: Slta Waiver <sltawvr@motorola.com>
Tested-by: Jira Key <jirakey@motorola.com>
Reviewed-by: Christopher Fries <qcf001@motorola.com>
Reviewed-by: Jason Hrycay <jason.hrycay@motorola.com>
Reviewed-by: Klocwork kwcheck <klocwork-kwcheck@sourceforge.mot.com>
Reviewed-by: Check Patch <CHEKPACH@motorola.com>
Submit-Approved: Jira Key <jirakey@motorola.com>
(cherry picked from commit 8aacc71ff8c7df743a1dfffbbc8e3190499299ae)

Signed-off-by: Luis Cruz <ljc2491@gmail.com>
Signed-off-by: poondog <markj338@gmail.com>
Revert "synaptics_3k: Improve touchscreen sensitivity"

This reverts commit 99320d08c45446f78aec01b32fef5e16dcd7b3f3.
Revert "synaptics_3k: Do not hardcode pressure & width"

This reverts commit 9977dd5335e96195e9e4b7b3de5444fb3790394a.
drivers:usb decrease PHY_SUSPEND_TIMEOUT_USEC to 200 (from 500) to hopefully reduce the msm_hsic_host wakelock duration and yield more deep sleep.

Referenced faux123 and franco commits:

https://github.com/franciscofranco/mako/commit/8c6220f32181e94fb3f627a8d959c22fdb532517

https://github.com/faux123/mako/commit/30073b70484987091b8f1203c5ecaa6046b72cbe

Also removes some debugging to my liking (franco)

seem to be able to quantify this change using better battery stats, but

Signed-off-by: morfic <morfic@gmail.com>

Conflicts:
	drivers/usb/host/ehci-msm2.c
USB: Allow skipping device resume during system resume

Some buses would like to keep their devices in suspend state during system
resume.  For example HSIC controller driver prevent system suspend when
HSIC device is active.  If this device is resumed, during system resume
HSIC controller acquire wake lock and prevent the subsequent suspend till
HSIC device is auto suspended.

CRs-Fixed: 403975
Change-Id: I93ccd874bf489190e4afb94b533db47bb2911db8
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Signed-off-by: poondog <markj338@gmail.com>

Conflicts:
	drivers/usb/core/driver.c
	include/linux/usb.h
USB: Prevent system suspend when HSIC device is active

Some buses like HSIC would like to keep device in suspend state
after system resume.  The remote wakeup or interface activity
later will auto resume the device.  This will work only if the
device is auto suspended before system suspend.  If the device
runtime state had been active during system suspend and system
suspend routine put the device in suspend, it will not be resumed
during system resume.  When remote wakeup happen for this device,
the runtime resume will not bring the device to active as runtime
core think it is already active.

The HSIC bus ensure that device is auto suspended prior to system
suspend by holding a wakelock till the bus is suspended.  HSIC bus
is not handling the case where device is auto resumed immediately
after system suspend begins.  HSIC bus simply put the device into
suspend in system suspend routine.

This patch fixes above issue by returning an error code if the device
is not auto suspended during system suspend.  Also add a safe guard
check in HSIC system resume routine to skip device resume only if it
is auto suspended prior to system suspend.

CRs-Fixed: 422876
Change-Id: I888585ed872d808aa4dbca33b529fcc32994349b
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Signed-off-by: poondog <markj338@gmail.com>

Conflicts:
	drivers/usb/core/driver.c
suspend: enter sleep state quickly
slimbus: Optimize overclocking of master component
* Add 44khz and 48khz to default SLIM RATES.
* Change root frequency to optimal value (11 was default)
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>