msm: mdss: account for peak bandwidth due to SMP fetch

At beginning of vsync, all pipes can start fetching at the same time in
order to fill their allocated SMP blocks, which is usually only enough
to hold first few lines of the layer. Account for this behavior and
ensure that there is enough bandwidth to fill these in the blanking
period.

Change-Id: Ic23e31813fe67958f741d52ab504ed683d23dd45
Signed-off-by: Adrian Salido-Moreno <adrianm@codeaurora.org>
Signed-off-by: flar2 <asegaert@gmail.com>
Signed-off-by: aatjitra <aatjitra@gmail.com>
msm: mdss: add back bus factors for bandwidth calculations

Bus factors are needed to account for how system behaves. AB factors is
needed due to the way bus driver is calculating the bandwidth by
dividing it across 2x ports. IB factor is needed to account for DDR
inefficiency and get the correct throughput.

Change-Id: Iccf83dd25615de489d8e986c38a6d2e9175a965c
Signed-off-by: Adrian Salido-Moreno <adrianm@codeaurora.org>
Signed-off-by: flar2 <asegaert@gmail.com>
Signed-off-by: aatjitra <aatjitra@gmail.com>
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: flar2 <asegaert@gmail.com>
Signed-off-by: aatjitra <aatjitra@gmail.com>

Conflicts:
	arch/arm/configs/hammerhead_defconfig