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

Change-Id: If91bb71ec272fcf04fb908c686e1739901199096
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

Change-Id: Iff57031c77068891740382a4b5e4aef56cc93b0a
Signed-off-by: Paul Reioux <reioux@gmail.com>
msm: mdss: Remove sysfs for unused commands

Change-Id: I76a1dd34730220ac20e122da81917f9614e1220e
msm: mdss: Identify white point in sysfs

Change-Id: Ie20ede22dda0dba7c69c6edfecc427e626635319
msm: mdss: Add safety check for user input

Leave more checks either to the control app or the user's intelligence.

Change-Id: I13f24c09bb9f4dd9da1ee2ac79eb85e08d5dadeb
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

Change-Id: Ice5ace99c1f11910d058a5f054085cac74169c50
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.

Change-Id: Ia757be43751960dac934801e0a91861cfbae7c72
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.

Change-Id: I2dbe34577405d9698a690637aec77d9626c7d797
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.

Change-Id: I39cec6e7e242d06883645e043687d4bf08f6f104
msm: mdss: Find a stable sysfs node for the gamma interface

Move sysfs files to /sys/module/dsi_panel/*

Change-Id: Ia0e5dbb902011c68b2c3e2b265e168092ac8db3b
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.

Change-Id: I3f955203339d110d2feff475b80f6f2db728b048
Revert "msm: mdss: Reset panel to apply RGB gamma data"

This reverts commit 3f955203339d110d2feff475b80f6f2db728b048.

Change-Id: I35eb715bf860c840ebc2457aa03da5565b44746e
Revert "msm: mdss: distinguish between Gamma RGB polarity Positive/Negative"

This reverts commit ff57031c77068891740382a4b5e4aef56cc93b0a.

Change-Id: I7208c6f8c752a2634cfce193592d8935a757f3bd
ARM/dt: hammerhead: Reduce minimum panel brightness

Default minimum brightness is a tad too high, this change makes reading
in a dark environment much more enjoyable. A value of 3 is still within
the valid range (see lm3630 blmap).

Change-Id: I40f690e7a06459a06db939c37108bae6fc9c52d6
Implement kexec-hardboot

"Allows hard booting (i.e., with a full hardware reboot) to a kernel
previously loaded in memory by kexec.  This works around the problem of
soft-booted kernel hangs due to improper device shutdown and/or
reinitialization."
More info in /arch/arm/Kconfig.

Original author: Mike Kasick <mike@kasick.org>

Vojtech Bocek <vbocek@gmail.com>:
  I've ported it to hammerhead, it is based of my mako/grouper port, which is
  based of Asus TF201 patch ported by Jens Andersen <jens.andersen@gmail.com>

  Hammerhead is the first device I've ported this patch to which uses
  device tree binary instead of atags. It is also rather picky - its
  bootloader erases first 128MB of RAM on reboot, so following hacks had
  to be applied:
  * Copy dtb to location passed in r2 before jumping to kexecd' kernel,
    the kernel would just freeze when I left dtb above 128MB of RAM.
  * Copy kexecd' kernel to location in the first 128MB before jumping to it,
    the decompressor operates very slowly if the kernel is above the cached
    area, copying it lower and decompressing it afterwards is much faster.

  Same as my mako/flo patches, the guest kernel does not require any
  modifications, kexec-hardboot is equivalent to standard kexec.

  To support dtb, following commit was backported from the mainline:
    commit 4cabd1d9625c7d88acd143f4021fbef75394f154
    Author: Matthew Leach <matthew.leach@arm.com>
    Date:   Fri Sep 21 18:56:02 2012 +0100

      ARM: 7539/1: kexec: scan for dtb magic in segments

      This patch allows a dtb to be passed to a new kernel using the kexec
      mechinism.

      When loading segments from userspace, scan each segment's first four
      bytes for the dtb magic. If this is found set the kexec_boot_atags
      parameter to the relocate_kernel code to the phyical address of this
      segment.

  and fixes of this commit:
    c564df4db85aac8d1d65a56176a0a25f46138064
    2456f44dd7a9aaffc2cd21a13f78198b3d94da08

ayysir <dresadd09691@gmail.com>:
  kexec: use mem_text_write_kernel_word to set reboot_code_buffer args
  in order to avoid protection faults (writes to read-only
  kernel memory) when CONFIG_STRICT_MEMORY_RWX is enabled.

Signed-off-by: Vojtech Bocek <vbocek@gmail.com>
Signed-off-by: Dennis Rassmann <showp1984@gmail.com>
[PATCH 1/3] block: cgroups, kconfig, build bits for BFQ-v7r3-3.4

Update Kconfig.iosched and do the related Makefile changes to include
kernel configuration options for BFQ. Also add the bfqio controller
to the cgroups subsystem.

Change-Id: If0aeebc591ada0df80eba0e41ae8bc25c626c548
Signed-off-by: Paolo Valente <paolo.valente@unimore.it>
Signed-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>
[PATCH 2/3] 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.

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