sync: signal pt before sync_timeline object gets destroyed

There is a race condition

Assume we have *one* sync_fence object, with *one* sync_pt
which belongs to *one* sync_timeline, given this condition,
sync_timeline->kref will have two counts, one for sync_timeline
(implicit) and another for sync_pt.

Assume following is the situation on CPU

Theead-1 : (Thread which calls sync_timeline_destroy())
  -> (some function calls)
   -> sync_timeline_destory()
    -> sync_timeline_signal() (CPU is inside this
function after putting reference to sync_timeline)

At this time Thread-2 comes and does following

Thread-2 : (fclose on fence fd)
> sync_fence_release() -> because of fclose() on fence object
 -> sync_fence_free()
  -> sync_pt_free()
   -> kref_put(&pt->parent->kref, sync_timeline_free);
    -> sync_timeline_free() (CPU is inside this because
this time kref will be zero after _put)

Thread-2 will free sync_timeline object before Thread-1
has finished its work inside sync_timeline_signal.

With this change we signals all sync_pt before putting
reference to sync_timeline object.

Change-Id: Ic680e4d0bbef1c46bcb7cfba693395645241d203
Signed-off-by: Prakash Kamliya <pkamliya@codeaurora.org>
Signed-off-by: Rom Lemarchand <romlem@google.com>
sync: Fix a race condition between release_obj and print_obj

Before this change, a timeline would only be removed from the timeline
list *after* the sync driver had its release_obj() called. However, the
driver's release_obj() may free resources needed by print_obj().

Although the timeline list is locked when print_obj() is called, it is
not locked when release_obj() is called. If one CPU was in print_obj()
when another was in release_obj(), the print_obj() may make unsafe
accesses.

It is not actually necessary to hold the timeline list lock when calling
release_obj() if the call is made after the timeline is unlinked from
the list, since there is no possibility another thread could be in --
or enter -- print_obj() for that timeline.

This change moves the release_obj() call to after the timeline is
unlinked, preventing the above race from occurring.

Signed-off-by: Alistair Strachan <alistair.strachan@imgtec.com>
cpufreq: interactive: restructure CPUFREQ_GOV_LIMITS

The cpufreq_interactive_timer gets cancelled and rescheduled
whenever the cpufreq_policy is changed. When the cpufreq policy is
changed at a rate faster than the sampling_rate of the interactive
governor, then the governor misses to change the target frequency
for long duration. The patch removes the need of cancelling the
timers when policy->min is changed.

Signed-off-by: Badhri Jagan Sridharan <Badhri@google.com>
Change-Id: I7862f1c8022a3b98a890e7537f93d02010e86764
cpufreq: interactive: turn boost_pulse off on boost off

Change-Id: I36fe217fa047d68ea90e78b12c7db4537ea8010b
Signed-off-by: Ruchi Kandoi <kandoiruchi@google.com>
LCD_KCAL: Color Control driver for Nexus 5
msm: mdss: Display gamma control

TODO: confirm rgb channels, identify other tunables, cleanup,
apply values without switching screen (off and) on.

sysfs: /sys/devices/qcom,mdss_dsi_jdi_command_ors.69/*
msm: mdss: Apply commands values without switching screen (off and) on
msm: mdss: Remove tunable for command 32

Even slight changes look ugly or distort the screen.
msm: mdss: distinguish between Gamma RGB polarity Positive/Negative

Signed-off-by: Paul Reioux <reioux@gmail.com>
msm: mdss: Remove sysfs for unused commands
msm: mdss: Identify white point in sysfs
msm: mdss: Add safety check for user input

Leave more checks either to the control app or the user's intelligence.
msm: mdss: Finalize gamma interface and cleanup

- Remove all sysfs files of unused commands
- Remove auto sync for negative polarities, these must be written separately
- Protect offset bit of white point command as well
- Apply white point bit 2 as duplicate of bit 1
msm: mdss: Send panel commands via separate function

Sending panel comnmands is very expensive, add a separate function to
accomplish this. Once all commands have been stored write anything to
the kgamma_send file.
msm: mdss: Add hardware revision check

Our gamma interface works with both current hardware revisions,
11 and 11j, although all testing was carried out on 11. As we
don't know about possible future revisions, let's bail out until
correct offsets for panel commands have been added.

Signed-off-by: Paul Reioux <reioux@gmail.com>
msm: mdss: Use workqueue to send panel commands

Sending panel commands is known to be expensive, honor this by
scheduling this task. Also check for panel state and send commands
only when we're actually awake.

These fixes adress bug reports regarding behaviour during boot.
msm: mdss: Find a stable sysfs node for the gamma interface

Move sysfs files to /sys/module/dsi_panel/*
msm: mdss: Reset panel to apply RGB gamma data

Writing to the reset gpios produces a short flicker. This however
appears to be the only reliable method to apply RGB gamma data
without switching the panel off and on again.
msm: mdss: Display gamma control (Squashed Commit)

Revert "msm: mdss: Reset panel to apply RGB gamma data"

This reverts commit db50c62a788e064ffe98c22580f293576036e116.

Revert "msm: mdss: distinguish between Gamma RGB polarity Positive/Negative"

This reverts commit 2ed978b9db44b2642d4fd949209b27c365b8f67c.

Change-Id: I4716af67993181005464ffac9389b818f8078adc