Revert "cpufreq: set lower min freq at boot"

This reverts commit 2a6b28a605f4f458917b4becfeec570ffff473c0.
Revert "mach-msm: cpufreq: set safe min/max frequencies when cpufreq is inizialize"

This reverts commit f1924735ef9312297cefffa4ab1c11a06d847ed7.
spi_qsd: Config GPIOs by name rather then by index

Currently GPIOs are identified (MISO/MOSI/CLK or CS0..3)
by their index in the device-tree entry's array.
Further, chipselect GPIOs must be declared in order.
This allows to set a value for GPIO number three only
if the values for GPIOs one and two are also set.
This patch allows the driver to identify GPIOs by a
unique name, thus allows to specify any arbitrary
chipselect GPIO and reduces chances of simple
user configuration error.

Signed-off-by: Gilad Avidov <gavidov@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
spi_qsd: correct the chip select gpios valid field entry

During probe Chip select gpio's valid field is set to non-zero.
This is causing gpio free to get called for not-used gpios
during runtime suspend.

Signed-off-by: Alok Chauhan <alokc@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
spi_qsd: Add support for multiple BAM descriptors

Currently SPI driver is queuing a single BAM descriptor
at a time. The BAM engine supports queuing of multiple
transfer descriptors.

Add support to spi driver to queue multiple descriptors.

CRs-Fixed: 546346
Change-Id: Iaee9b3b362832262b75e46e19ad18552d037620b
Signed-off-by: Alok Chauhan <alokc@codeaurora.org>
Signed-off-by: Sana Venkat Raju <c_vsana@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
spi_qsd: Fix bug in multi-xfer bam mode transaction

Spi doesn't handle multiple xfer per message scenario
(eg:Rd->Wr or Wr->Rd) correctly and spi request
stuck indefinetly in while loop when total byte count
is not 0.

increment both(rx,tx) references so next bam
transaction will be queued correctly. Flush the
bam pipes after each transactions.

CRs-Fixed: 637693
Change-Id: I455df38be2f9687b1eb2a704466f6974dfb83a22
Signed-off-by: Alok Chauhan <alokc@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
cpufreq: bacon: Exercise hispeed settings at a policy level

If a heavy task migrates between otherwise idle CPUs in a policy during
every sample window, the above hispeed delay window for the CPUs would get
restarted for every sample window. Due to the continuous restart of above
hispeed delay window, none of the CPUs would ever pick a target frequency
higher than hispeed frequency. This causes the policy's frequency to be
stuck at hispeed freq even if the load justifies a higher frequency.

To fix this, the above high speed delay window is restarted only when the
policy frequency changes. This ensures that tasks migrating between CPUs in
a policy are handled correctly.

Also, the hispeed load/frequency heuristic is only necessary when the
information is insufficient to determine if the load on the CPU needs at
least hispeed frequency. When the policy frequency is already at or above
hispeed frequency, if the CPU load% based on policy frequency is not above
hispeed load, then the information is clearly sufficient to determine that
the load on the CPU does not need hispeed frequency.

Therefore, compute CPU load% (which is used only to compare against hispeed
load) based on policy frequency instead of CPU target frequency.

Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
arK 0.8.1.exp