USB: ci13xxx_udc: Skip flushing endpoints upon failure

Flushing an endpoint involve polling ENDPTFLUSH and ENDPTSTAT
registers.  The worst case timeout is 100 msec for each endpoint.
The reason for failure is unknown.  When flushing an endpoint
fails, successive flushing of remaining endpoints are also failing.
Hence skip flushing remaining endpoints.  Reset this condition
upon USB bus reset.

(cherry picked from commit 2a630fb9b83b31e607ef61f3b61959cc1b095349)

CRs-Fixed: 445916
Change-Id: I54cf860c0d290ffa3fc0d7e41af32b4be48937ef
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
USB: ci13xxx_udc: Fix possible NULL pointer dereference

Don't access dev->platform_data before checking dev against NULL.

CRs-fixed: 440043
(cherry picked from commit bb4cd9eb06da6275256dee09a88c472b90d191a8)

Change-Id: I6270aef1cc364fac58be0d216e2255592306a28f
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
sched: pack small tasks
Date	Fri, 22 Mar 2013 13:25:52 +0100

During the creation of sched_domain, we define a pack buddy CPU for each CPU
when one is available. We want to pack at all levels where a group of CPU can
be power gated independently from others.
On a system that can't power gate a group of CPUs independently, the flag is
set at all sched_domain level and the buddy is set to -1. This is the default
behavior.
On a dual clusters / dual cores system which can power gate each core and
cluster independently, the buddy configuration will be :

      | Cluster 0   | Cluster 1   |
      | CPU0 | CPU1 | CPU2 | CPU3 |
-----------------------------------
buddy | CPU0 | CPU0 | CPU0 | CPU2 |
Small tasks tend to slip out of the periodic load balance so the best place
to choose to migrate them is during their wake up. The decision is in O(1) as
we only check again one buddy CPU

Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
Reviewed-by: Morten Rasmussen <morten.rasmussen@arm.com>

Conflicts:
	kernel/sched/fair.c
sched: secure access to other CPU statistics
Date	Fri, 22 Mar 2013 13:25:53 +0100

If a CPU accesses the runnable_avg_sum and runnable_avg_period fields of its
buddy CPU while the latter updates it, it can get the new version of a field
and the old version of the other one. This can generate erroneous decisions.
We don't want to use a lock mechanism for ensuring the coherency because of
the overhead in this critical path. The previous attempt can't ensure
coherency of both fields for 100% of the platform and use case as it will
depend of the toolchain and the platform architecture.
The runnable_avg_period of a runqueue tends to the max value in less than
345ms after plugging a CPU, which implies that we could use the max value
instead of reading runnable_avg_period after 345ms. During the starting phase,
we must ensure a minimum of coherency between the fields. A simple rule is
runnable_avg_sum <= runnable_avg_period.

Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
Reviewed-by: Morten Rasmussen <morten.rasmussen@arm.com>
sched: pack the idle load balance
Date	Fri, 22 Mar 2013 13:25:54 +0100

Look for an idle CPU close to the pack buddy CPU whenever possible.
The goal is to prevent the wake up of a CPU which doesn't share the power
domain of the pack buddy CPU.

Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
Reviewed-by: Morten Rasmussen <morten.rasmussen@arm.com>
modified for Mako hybrid kernel

Signed-off-by: faux123 <reioux@gmail.com>