intelli_plug: fix incorrect cpufreq API usage

This resolves the wakeup kick and screen off max issues

Signed-off-by: Paul Reioux <reioux@gmail.com>
intelli_plug: initialize ip_info struct element during driver init

this will eliminate race issues

Signed-off-by: Paul Reioux <reioux@gmail.com>
intelli_plug: use primary CPU's info data for non-boot cpu's settings

Async CPU design has caused quite a bit of grief for controlling cpu
frequencies

bump to version 3.8

Signed-off-by: Paul Reioux <reioux@gmail.com>
intelli_plug: older Qualcomm kernel compatibility fixup

ARGH... really angry at CAF code.

some cpufreq driver APIs are incredibly unstable with some of the older
MSM kernels.  The correct way is the fix the cpufreq drivers, but there are
tons of variations out there, so rather than depending on a fix, make
intelli_plug more universal by avoiding the troubling APIs altogether

Signed-off-by: Paul Reioux <reioux@gmail.com>
usb: gadget: Ignore the second set_config from the host

Some USB hosts may send SET_CONFIGURATION with same value twice.
The current code implementation of android_work() issues disconnect
event to userspace if SetConfiguration with non-zero value is sent
twice. The Userspace application may disconnect USB and it causes
fail to connect to the USB host.

Fix this by ignoring the second time SET_CONFIGURATION request
from the host only for the same configuration value twice.

CRs-Fixed: 661220
Change-Id: Iec8dd7824fa9f371ea147784cf9137aa88a7128e
Signed-off-by: ChandanaKishori Chiluveru <cchilu@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
USB: android: release spinlock before queuing work in android_setup

In android_setup we release spinlock after scheduling the work but there
is no need for holding the spinlock during the schedule_work call
is executed this can lead to spinlock timeouts in case where schedule
work takes more time.

So before scheduling work in android_setup we release spinlock to avoid
potential spinlock lockup or timeout.

Signed-off-by: Tarun Gupta <tarung@codeaurora.org>
Signed-off-by: Vijayavardhan Vennapusa <vvreddy@codeaurora.org>
Signed-off-by: ChandanaKishori Chiluveru <cchilu@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
usb: android: Skip the work when set_config arrives with same value twice

Some USB hosts may send SET_CONFIGURATION with same value twice.
The current code implementation processing the 2nd set_config and
schedules the work. The android_work() issues disconnect event to
userspace if SetConfiguration with non-zero value is sent twice.
The userspace applications may disconnect the USB and the device
doesn't connect to the host.

Fix this by avoiding the android_work for the second time SET_CONFIGURATION
request when it receives SetConfiguration request with same configuration
value twice from the host.

Signed-off-by: ChandanaKishori Chiluveru <cchilu@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
overall_stats: add overall stats for all available cores

this is much more accurate stats tracking than just displaying core 0's
stats from most other kernels

Signed-off-by: faux123 <reioux@gmail.com>
overall_stats: make dual/quad core stats configurable via meunconfig

Signed-off-by: faux123 <reioux@gmail.com>
overall_stats: forward port to kernel 3.4+

by replacing deprecated functions with native add/sub for 64bit data types

Signed-off-by: faux123 <reioux@gmail.com>
cpufreq: Resolve CPUFREQ_NOTIFY issue

When the cpufreq_stat receives the frequency policy notification,
it checks if the frequency table and stats table are present for the cpu.
If both are present, it returns with -EBUSY error to the notification.
Due to this, none of the other registered modules receive this
notification.

If the stat table and sysfs nodes are already created, return 0 instead
of returning EBUSY error.

Change-Id: I1fd4a46e6a65edfc6253c4271288f10912ae2ad7
Signed-off-by: Archana Sathyakumar <asathyak@codeaurora.org>
Fix cpufreq_stats.c Use u64 instead cputime64_t

https://github.com/torvalds/linux/commit/1e7586a18a2ab69a160837c0a4be31f7147cfb5e