pmic: rk808: slove set voltage error

rk808 setting voltage had a overshoot question
so we set voltage must step by step.
support 12.5mv/step.

Change-Id: Idfce7b57d6717e51afaff2c170eff7bd16de23af
Signed-off-by: zhangqing <zhangqing@rock-chips.com>

ARM: dts: fix some code style issues

Change-Id: I3f1f5637729171079ca7d108ba59521018c9561d
Signed-off-by: Chris Zhong <zyw@rock-chips.com>

video: rockchip: hdmi: 3368: support vesa dmt mode

Change-Id: Ic2a910cd50beb9b49baff7bd732f6c1bdd78790f
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>

video: rockchip: hdmi: 3288/3368: phy pll support more vesa dmt clock

Change-Id: I7382e5554664f2014bb5aa579a2524bf1738d971
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>

video: rockchip: hdmi: support some vesa dmt mode

Change-Id: I28e935c717ae69fb2b48a7c243f8ce3cc7101a86
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>

ARM: dts: add a alias for rockchip_suspend

Since we need overwrite this rockchip_suspend node in sub dts file,
sometimes. Add a alias for before it.

Change-Id: I6d951d1c0bfff1cde619906eb9f11256d057a9fe
Signed-off-by: Chris Zhong <zyw@rock-chips.com>

media: camsys_soc_priv: use cpu_is_rk3288 instead of soc_is_rk3288

Change-Id: If54087f71e0b6c923a11a6a37a4420ba86211070
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>

video: fbdev: Add additional vesa modes

Change-Id: I485601d679687db9a655f06b48929e66883bdadd
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>

pinctrl: rockchip: fix rk3288 gpio0 configuration

On rk3288, for gpio bank 0, the registers which configure pull-up,
iomux, and drive strength don't implement the enable bits in the upper
half of the register, unlike the other gpio configuration registers,
and so the kernel must perform a read-modify-write of the register to
update a particular gpio in that bank.

Change-Id: I4a6953839307e3a75b2ac554aac3dc865583617d
Signed-off-by: Chris Zhong <zyw@rock-chips.com>

video: rockchip: fb: resize uboot logo if screen size is changed

If hdmi is inserted or removed before android is launched, screen
size is changed and uboot logo is showing on wrong screen position.

For example, screen size is 720x576 in uboot, hdmi is inserted during
kernel is booting, screen size is changed to 1920x1080, logo size
is still 720x576 and shown on left-top.

This case is occurred on box, mid has no problem. So we need to resize
uboot logo to new screen size.

Change-Id: I6247bf8e77d181687986815c960ec72d4c59a757
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>

ddrfreq: rockchip: read the parameters of auto-freq from dts

Change-Id: I50ff96bc66d929009da99b53c39d4b95567ad100
Signed-off-by: Xiao Feng <xf@rock-chips.com>

arm64: rockchip: rk3368: dts: add the parameters of auto-freq in dts

Change-Id: I8b19961a8a93b1ceb4378b1100d3f4cc8a5a9baa
Signed-off-by: Xiao Feng <xf@rock-chips.com>

ARM: dts: rk3368 box add xz3216 dcdc support

Change-Id: I91fab0816784bbdec36b2347f3e911fd402bc83e
Signed-off-by: Huang zhibao <hzb@rock-chips.com>

dcdc: add xz3216 dcdc support

Change-Id: I887e96c981af0cfffdb1c08784c52c774bb16fab
Signed-off-by: Huang zhibao <hzb@rock-chips.com>

video: rockchip: rb: return error value to user when an exception is configed

Change-Id: I81697f24c6914f07f8facad4e23ad4fb6824190c
Signed-off-by: Huang Jiachai <hjc@rock-chips.com>

of/device: Fix platform_device.name point to an freed memory after
dev_set_name()

When we use of_device_add() to create platform_device and add it to device
hierarchy, the platform_device.name and device's name will point to the same
memory.

Later we use dev_set_name() to change the device's name, it will alloc new
memory to store name and free old device's name. After it, the
platform_device.name will point to an freed memory, access platform_device.name
 maybe lead to unpredictable exceptions.

So, we alloc new memory for platform_device.name in of_device_add()

Change-Id: I59bf0941ee4e094053971d41d386206e47fddcaa
Signed-off-by: Meiyou Chen <cmy@rock-chips.com>

rk3368 dts: add ddr timing node in rk3368.dtsi

Change-Id: Ib1887e65567c76fc93b0a23ba143f9ad7e80b99f
Signed-off-by: Tang Yun ping <typ@rock-chips.com>

rk312x ddr: fix get bandwidth error

1.Using 64bit width variable to cached the read and write data bandwidth
because it may overflow when calculating read and write data bandwidth.
2.Get ddr burst length to calculating bandwidth because lpddr2's burst
length may be bl4 or bl8.

Change-Id: I28db1793e411fc3e18edc3b6421ab3d397d92aa5
Signed-off-by: Tang Yun ping <typ@rock-chips.com>

Pmic: rk808: Move regulator init parameters from rk808.dtsi to board dts

Move rk808 regulator init parameters to the rk3xx-xx.dts
Convenient for different products setting and modify

Change-Id: I03673f4dbd478df0630e6b982e72597ade14d810
Signed-off-by: zhangqing <zhangqing@rock-chips.com>

video: rockchip: hdmi: 3368: enable detect phy pll lock status

Phy PLL may be unlock under electro-static test. The higher the
electro-static voltage, the more likely the PLL will be lost.
If PLL is unlock and irq is triggered, we will reset registers
to make it lock on correct frequency.

Change-Id: I86eaa660e837e8c2e59c8e39e3ce083bb89c1bac
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>

rk808: fix a err when no sleep pin in dts

Rk808 will data abort if it has not sleep gpio in dts, and there is no
pmic_sleep_gpio for some board, add a validity checking before
gpio_request can fix this data abort.

Change-Id: Ic2b40f7bfb00e95d283dce72a33dd844cc2c7e27
Signed-off-by: Chris Zhong <zyw@rock-chips.com>

tve: rk1000: modify process, make it more reasonable

Change-Id: I021682c0da4e3096ceadf7b8e320a7391c55208b
Signed-off-by: Shen Zhenyi <szy@rock-chips.com>

rk3368 DDR: using unified smc call and get trust firmware version function

Change-Id: I81d5fae0a3679081d35d137500e20d5dd705eb15
Signed-off-by: Tang Yun ping <typ@rock-chips.com>

rk3288: pwm: rkpwm use same interrupt, voppwm would not use capture mode

Change-Id: Ic4d27adeb800406efa1efa5b34fc78677b4def72
Signed-off-by: David Wu <wdc@rock-chips.com>

dtsi: rk312x-sdk: update rk818 battery node

Change-Id: I1d0dd1b005e94281cff0792e6380deb3f02efaaf
Signed-off-by: Jianhong Chen <chenjh@rock-chips.com>

dts: rk3288-tb: update rk818 battery node

Change-Id: I4a76e7ac0ff3af791839ab5e5f9656ce72612dd1
Signed-off-by: Jianhong Chen <chenjh@rock-chips.com>

power: rk81x-battery: fix charge termination voltage define error

the charge termination voltage configration is like bellow:

000: 4.05v, 001: 4.10v, 010: 4.15v
011: 4.20v, 100: 4.25v, 101: 4.30v
110: 4.35v, 111: 4.35v

Change-Id: I17c7df5952c3913eaf509ae2603f2d96d7ea96c8
Signed-off-by: Jianhong Chen <chenjh@rock-chips.com>

usb: dwc_otg_310: gadget: stop current transfer on dequeue

If the request being dequeued is already started, disable endpoint
to stop the transfer and then call dwc_otg_request_done().
Endpoint will be re-enabled on next call to dwc_otg_ep_start_transfer().

TEST=use RK3128/RK3288/RK3368 board, adb root and then adb reboot,
check if usb_req->buf is used after free.

Change-Id: I8c9304f29c578f679ad0841350920f1350bd32df
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>

video: rockchip: hdmi: introduce vic flag HDMI_UBOOT_NOT_INIT

If uboot_vic has HDMI_UBOOT_NOT_INIT flag, it means uboot just
pass the preset vic value, registers has not been set in uboot.
If not, hdmi has been power up in uboot, should not operate phy
register again.

Change-Id: I64f48bd878ec124a94f25a752a74dc9bae502b2b
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>

rk3368 tb: enable fiq debugger and disable the original uart console

Change the device from ttyS2 to ttyFIQ0

Change-Id: Ibc2ab1c9adf1dd5d1718c3c2d80fe578725b409a
Signed-off-by: Huibin Hong <huibin.hong@rock-chips.com>

rk3368: add fiq debugger node in rk3368.dtsi

Change-Id: Iecbfd409d18b5a963bacbbc277e4d7157fe20fb7
Signed-off-by: Huibin Hong <huibin.hong@rock-chips.com>

rk3368: add fiq debugger config, and enabled default

Change-Id: Idc36f89d82e739e37153117bea20ecca1f5d516c
Signed-off-by: Huibin Hong <huibin.hong@rock-chips.com>

rk3368: add fiq debugger for rk3368

It is also for the later soc based on arch v8

Change-Id: I5e4fef1fa4176ea371b1653ead8cef87e4ac0e6f
Signed-off-by: Huibin Hong <huibin.hong@rock-chips.com>

rockchip: add psci interfaces for other modules

Change-Id: I000e3033305f695a8929fbab98a87eea608e76cd
Signed-off-by: Huibin Hong <huibin.hong@rock-chips.com>

rockchip: add dts spec for fiq debugger

Documentation/devicetree/bindings/serial/rockchip_fiq_debugger.txt

Change-Id: Iab6cd308aed816ad614006a155816cd3e32df6f6
Signed-off-by: Huibin Hong <huibin.hong@rock-chips.com>

ASoC: rockchip: spdif: increase dma burst size

increase dma burst size from 4 to 16 to optimize dma transfer.

Change-Id: I1a9112e6b89ed1f29d24a3e4b5f42bf4201a9e71
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>

video: rockchip: fb: close rk_fb_iommu_debug default

Change-Id: I285c091fe2932906070eb861ce98943b4605e101
Signed-off-by: Huang Jiachai <hjc@rock-chips.com>

ARM: dts: rk3288: move the remote-ctrl of PWM into box dts

Thinking about the PWM remote-ctrl is used by box, we should
put this into box dts.

Meanwhile, that PWM configure will break the normal PWM driver.
This patch will fix it.

Change-Id: I14878332631f94f512412ced5ceb8689f8bfbe46
Signed-off-by: huang zhibao <hzb@rock-chips.com>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>

ARM: dts: rk3288: add the interrupts property for PWM

We are assuming that PWM need use the property, we can support the
SPI interrupts for PWM.

At the moment, we can find the remotectl pwm is needed on box.
We can add the property for all PWMs. AFAIK, the pwm driver don't use it
but the drivers/input/remotectl/rockchip_pwm_remotectl.c

Change-Id: Ia223e6cc0e882477614b555bd09c86fd4bf8dbd7
Signed-off-by: Caesar Wang <wxt@rock-chips.com>

cpufreq: rockchip: change the frequency of cci400 dynamically

when the frequency of big cluster and little cluster are bigger then
600MHz, set the frequency of cci400 to 576MHz, otherwise set the
frequency of cci400 to 288MHz.

Change-Id: I9e28b51bfdfcaf62464b8511c731fa2cd0ed5d9d
Signed-off-by: Xiao Feng <xf@rock-chips.com>

USB: dwc_otg_310: hcd: modify reboot or shutdown painc

When reboot or shutdown, hcd clean urbs and disable host interrupts. But
there may pending interrupts, so clean them.

Change-Id: Ide34aab5857a790a0912fb56ebe18d43ba228cf0
Signed-off-by: Feng Mingli <fml@rock-chips.com>
Signed-off-by: Yunzhi Li <lyz@rock-chips.com>

USB: dwc_otg_310: release channel for qtd that has been dequeued before

Change-Id: I184ed185074b2ccee24cbbf57c9ff1dad06bd9d7
Signed-off-by: Yunzhi Li <lyz@rock-chips.com>

ANDROID: input: elan_i2c: add elan touchpad driver

SMbus and I2C handling from driver core into separate
transport modules and makes them optional.

This driver pick up from chromium 3.14-kernel
Here is the URL:
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/v3.14

----Note a bit different-----
we can easy replace the reinit_completion(completion);
with "completion->done = 0" in driver.

Change-Id: Idf373a502faea7913889f4a2f14ba71cae0da5b8
Signed-off-by: Caesar Wang <wxt@rock-chips.com>

ANDROID: input: Add "inhibited" property for input devices

Under certain circumstances, we want to disable some input
devices from userspace. In particular, when we detect that the lid of a
laptop is closed, we want to be able to disable touchpad and
touchscreen to avoid bogus input.

To facilitate this, we introduce the "inhibited" sysfs property for
input devices. Using this property, userspace can tell a driver that the
events it can provide are not currently of interest and should be
ignored. We provide hooks so that the driver can take additional
actions, such as powering down the device.

We deliberately keep this limited to input devices for now to keep the
implementation as straightforward as possible.

(cherry-pick from: https://chromium-review.googlesource.com/207989)

verify that touchpad works
echo 1 > /sys/bus/i2c/drivers/elan_i2c/4-0015/input/input0/inhibited
touchpad stops working
echo 0 >  /sys/bus/i2c/drivers/elan_i2c/4-0015/input/input0/inhibited
touchpad works again

Signed-off-by: Patrik Fimml <patrikf@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207989
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
Change-Id: I889d37ef7ffc49f3c073b1c283d5c3327c263b7f
Signed-off-by: Caesar Wang <wxt@rock-chips.com>

sysfs: add sysfs_create/remove_groups()

commit 3e9b2bae8369661070622d05570cbcdfa01770e6 upstream

These functions are being open-coded in 3 different places in the driver
core, and other driver subsystems will want to start doing this as well,
so move it to the sysfs core to keep it all in one place, where we know
it is written properly.

Conflicts:
git checkout drivers/base/bus.c, In actul we don't use the interfaces in
drivers/base/bus.c

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Change-Id: I0046a5572c780a0ea2b175ef753c408f6c10ba85
Signed-off-by: Caesar Wang <wxt@rock-chips.com>

hdmi: rk3288: No need to enable scrambling again in uboot mode

If scrambling mode is enabled in uboot and set again in kernel,
picture will flicker serveral frame.

Change-Id: Ib8fe0b1e2ce2a74eb10fcfbb6c8eb872452cfd20
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
Reviewed-on: https://10.10.10.29/30
Tested-by: Huang, Tao <huangtao@rock-chips.com>
Reviewed-by: Huang, Tao <huangtao@rock-chips.com>

Documentation: add rockchip,rk3368-lcdc to rockchip_lcdc.txt

Change-Id: I8a88116f65aff7b594c87e67e5aef25a262e7b8a
Signed-off-by: Huang Jiachai <hjc@rock-chips.com>
Reviewed-on: https://10.10.10.29/27
Reviewed-by: Zheng Yang <zhengyang@rock-chips.com>
Tested-by: Huang, Tao <huangtao@rock-chips.com>
Reviewed-by: Huang, Tao <huangtao@rock-chips.com>

rk3368 lcdc: Update coding style

Change-Id: I84175f75e05d54394ff6eb20495cb89a17292b52
Signed-off-by: Huang Jiachai <hjc@rock-chips.com>
Reviewed-on: https://10.10.10.29/25
Reviewed-by: Zheng Yang <zhengyang@rock-chips.com>
Reviewed-by: Huang, Tao <huangtao@rock-chips.com>
Tested-by: Huang, Tao <huangtao@rock-chips.com>

hdmi:rk3288/rk3368: No need to reset tmdsclk in uboot mode.

If hdcp is enalbed, reset tmdsclk in uboot mode will make hdcp unstable,
which make sink check hdcp failed and show black picture.

Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>

rk3368 lcdc: lineflag1 line number move to uboot, because we don't know hdmi/cvbs vmode

Signed-off-by: hjc <hjc@rock-chips.com>

RK3368 DDR: new ddr change freq method

Using fiq to notify trust to stop cpu when ddr changing freq.
1.bl30 must update to rk3368bl30_v2.10.bin  and bl31 must update to
rk3368bl31_v1.5.bin.
2.Insure kernel commit 7643ffa0e67d5 and cc6e554e54fe1 were merged.

Change-Id: I2449613221c49a49ba14dab54e77714e961dcd16
Signed-off-by: Tang Yun ping <typ@rock-chips.com>

RK3368 Scpi: add Scpi version check

Signed-off-by: Tang Yun ping <typ@rock-chips.com>

 bcmdhd wifi:update driver 1.201.59.5

hdmi:rk3288/rk3368: support lte_340mcsc_scramble.

If EDID indicate sink support lte_340mcsc_scramble, we enable scrambing mode.

Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>

hdmi:rk3288/rk3368: clear scrambling bit and SCDC register when switching to v1.4 mode.

Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>

rk3368 lcdc: In advance 500us to trigger lineflage1x interrupt

Signed-off-by: hjc <hjc@rock-chips.com>

mailbox: rk3868 change max_chan_num attribute to static

Signed-off-by: Tang Yun ping <typ@rock-chips.com>

mailbox: rk3868: Added mailbox channel management function and fixed the bug of mailbox timeout.

Signed-off-by: Frank Wang <frank.wang@rock-chips.com>

dts: rk3368.dtsi: Configured SCPI mbox to 3 channels.

Signed-off-by: Frank Wang <frank.wang@rock-chips.com>

rk3368: usb: reset usb phy when channel halt

Signed-off-by: lyz <lyz@rock-chips.com>

rk_fb: video: fix YUV422/YUV422_10 uv_stride calc

Signed-off-by: Mark Yao <mark.yao@rock-chips.com>

mmc: dw_mmc-rockchip: limit phase for WA

Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>

mmc: rk_sdmmc: reset cmd_status before request

Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>

mmc: rk_sdmmc: fix SW-IOMMU memory leak

We could quickly reproduce this bug by decrease IO_TLB_DEFAULT_SIZE
and manually disable mmc DTO interrupt which can make driver fall into
post_tmo all the time.

So, some of these dump for swiotlb we can get here due to no enough
IO_TLB can be used to map page for kernel space:

DMA: Out of SW-IOMMU space for 128 bytes at device ff0f0000.rksdmmc
DMA: Out of SW-IOMMU space for 128 bytes at device ff0f0000.rksdmmc
...
DMA: Out of SW-IOMMU space for 128 bytes at device ff0f0000.rksdmmc
DMA: Out of SW-IOMMU space for 128 bytes at device ff0f0000.rksdmmc

Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Reported-and-tested-by: Jianhong Chen <chenjh@rock-chips.com>
Cc: Yao Xiao <xy@rock-chips.com>

ASoC: spdif: fix spdif work abnormally when xrun occurs.

when xrun occurs, it will do snd_pcm_stop to disable spdif
and then clear logic, next snd_pcm_lib_write1 will trigger
snd_pcm_start to enable spdif, but not to excute hw_params
to configue spdif, so need to save spdif configuration to
reconfigure spdif.

Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>

USB: dwc_otg_310: modify usb mode change detect bug

When dwc controller change mode form device to host, may check_vbus_work is running
on other cpu, but we don't have a good synchronization id_status_change and
check_vbus_work, as a result, phy and clk may in incorrect state. So modify it.

Signed-off-by: Feng Mingli <fml@rock-chips.com>
Signed-off-by: lyz <lyz@rock-chips.com>
Conflicts:
drivers/usb/dwc_otg_310/dwc_otg_pcd_linux.c

ASoC: rk312x: fix rk3128 codec right channel output

changed codec register order according to IP datasheet  to fix
right channel no output when low volume

Signed-off-by: luoxt <lxt@rock-chips.com>
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>

mm/vmalloc: fix possible exhaustion of vmalloc space caused by vm_map_ram allocator

Recently I came across high fragmentation of vm_map_ram allocator:
vmap_block has free space, but still new blocks continue to appear.
Further investigation showed that certain mapping/unmapping sequences
can exhaust vmalloc space.  On small 32bit systems that's not a big
problem, cause purging will be called soon on a first allocation failure
(alloc_vmap_area), but on 64bit machines, e.g.  x86_64 has 45 bits of
vmalloc space, that can be a disaster.

1) I came up with a simple allocation sequence, which exhausts virtual
   space very quickly:

  while (iters) {

                /* Map/unmap big chunk */
                vaddr = vm_map_ram(pages, 16, -1, PAGE_KERNEL);
                vm_unmap_ram(vaddr, 16);

                /* Map/unmap small chunks.
                 *
                 * -1 for hole, which should be left at the end of each block
                 * to keep it partially used, with some free space available */
                for (i = 0; i < (VMAP_BBMAP_BITS - 16) / 8 - 1; i++) {
                        vaddr = vm_map_ram(pages, 8, -1, PAGE_KERNEL);
                        vm_unmap_ram(vaddr, 8);
                }
  }

The idea behind is simple:

 1. We have to map a big chunk, e.g. 16 pages.

 2. Then we have to occupy the remaining space with smaller chunks, i.e.
    8 pages. At the end small hole should remain to keep block in free list,
    but do not let big chunk to occupy remaining space.

 3. Goto 1 - allocation request of 16 pages can't be completed (only 8 slots
    are left free in the block in the #2 step), new block will be allocated,
    all further requests will lay into newly allocated block.

To have some measurement numbers for all further tests I setup ftrace and
enabled 4 basic calls in a function profile:

        echo vm_map_ram              > /sys/kernel/debug/tracing/set_ftrace_filter;
        echo alloc_vmap_area        >> /sys/kernel/debug/tracing/set_ftrace_filter;
        echo vm_unmap_ram           >> /sys/kernel/debug/tracing/set_ftrace_filter;
        echo free_vmap_block        >> /sys/kernel/debug/tracing/set_ftrace_filter;

So for this scenario I got these results:

BEFORE (all new blocks are put to the head of a free list)
# cat /sys/kernel/debug/tracing/trace_stat/function0
  Function                               Hit    Time            Avg             s^2
  --------                               ---    ----            ---             ---
  vm_map_ram                          126000    30683.30 us     0.243 us        30819.36 us
  vm_unmap_ram                        126000    22003.24 us     0.174 us        340.886 us
  alloc_vmap_area                       1000    4132.065 us     4.132 us        0.903 us

AFTER (all new blocks are put to the tail of a free list)
# cat /sys/kernel/debug/tracing/trace_stat/function0
  Function                               Hit    Time            Avg             s^2
  --------                               ---    ----            ---             ---
  vm_map_ram                          126000    28713.13 us     0.227 us        24944.70 us
  vm_unmap_ram                        126000    20403.96 us     0.161 us        1429.872 us
  alloc_vmap_area                        993    3916.795 us     3.944 us        29.370 us
  free_vmap_block                        992    654.157 us      0.659 us        1.273 us

SUMMARY:

The most interesting numbers in those tables are numbers of block
allocations and deallocations: alloc_vmap_area and free_vmap_block
calls, which show that before the change blocks were not freed, and
virtual space and physical memory (vmap_block structure allocations,
etc) were consumed.

Average time which were spent in vm_map_ram/vm_unmap_ram became slightly
better.  That can be explained with a reasonable amount of blocks in a
free list, which we need to iterate to find a suitable free block.

2) Another scenario is a random allocation:

  while (iters) {

                /* Randomly take number from a range [1..32/64] */
                nr = rand(1, VMAP_MAX_ALLOC);
                vaddr = vm_map_ram(pages, nr, -1, PAGE_KERNEL);
                vm_unmap_ram(vaddr, nr);
  }

I chose mersenne twister PRNG to generate persistent random state to
guarantee that both runs have the same random sequence.  For each
vm_map_ram call random number from [1..32/64] was taken to represent
amount of pages which I do map.

I did 10'000 vm_map_ram calls and got these two tables:

BEFORE (all new blocks are put to the head of a free list)

# cat /sys/kernel/debug/tracing/trace_stat/function0
  Function                               Hit    Time            Avg             s^2
  --------                               ---    ----            ---             ---
  vm_map_ram                           10000    10170.01 us     1.017 us        993.609 us
  vm_unmap_ram                         10000    5321.823 us     0.532 us        59.789 us
  alloc_vmap_area                        420    2150.239 us     5.119 us        3.307 us
  free_vmap_block                         37    159.587 us      4.313 us        134.344 us

AFTER (all new blocks are put to the tail of a free list)

# cat /sys/kernel/debug/tracing/trace_stat/function0
  Function                               Hit    Time            Avg             s^2
  --------                               ---    ----            ---             ---
  vm_map_ram                           10000    7745.637 us     0.774 us        395.229 us
  vm_unmap_ram                         10000    5460.573 us     0.546 us        67.187 us
  alloc_vmap_area                        414    2201.650 us     5.317 us        5.591 us
  free_vmap_block                        412    574.421 us      1.394 us        15.138 us

SUMMARY:

'BEFORE' table shows, that 420 blocks were allocated and only 37 were
freed.  Remained 383 blocks are still in a free list, consuming virtual
space and physical memory.

'AFTER' table shows, that 414 blocks were allocated and 412 were really
freed.  2 blocks remained in a free list.

So fragmentation was dramatically reduced.  Why? Because when we put
newly allocated block to the head, all further requests will occupy new
block, regardless remained space in other blocks.  In this scenario all
requests come randomly.  Eventually remained free space will be less
than requested size, free list will be iterated and it is possible that
nothing will be found there - finally new block will be created.  So
exhaustion in random scenario happens for the maximum possible
allocation size: 32 pages for 32-bit system and 64 pages for 64-bit
system.

Also average cost of vm_map_ram was reduced from 1.017 us to 0.774 us.
Again this can be explained by iteration through smaller list of free
blocks.

3) Next simple scenario is a sequential allocation, when the allocation
   order is increased for each block.  This scenario forces allocator to
   reach maximum amount of partially free blocks in a free list:

  while (iters) {

                /* Populate free list with blocks with remaining space */
                for (order = 0; order <= ilog2(VMAP_MAX_ALLOC); order++) {
                        nr = VMAP_BBMAP_BITS / (1 << order);

                        /* Leave a hole */
                        nr -= 1;

                        for (i = 0; i < nr; i++) {
                                vaddr = vm_map_ram(pages, (1 << order), -1, PAGE_KERNEL);
                                vm_unmap_ram(vaddr, (1 << order));
                }

                /* Completely occupy blocks from a free list */
                for (order = 0; order <= ilog2(VMAP_MAX_ALLOC); order++) {
                        vaddr = vm_map_ram(pages, (1 << order), -1, PAGE_KERNEL);
                        vm_unmap_ram(vaddr, (1 << order));
                }
  }

Results which I got:

BEFORE (all new blocks are put to the head of a free list)

# cat /sys/kernel/debug/tracing/trace_stat/function0
  Function                               Hit    Time            Avg             s^2
  --------                               ---    ----            ---             ---
  vm_map_ram                         2032000    399545.2 us     0.196 us        467123.7 us
  vm_unmap_ram                       2032000    363225.7 us     0.178 us        111405.9 us
  alloc_vmap_area                       7001    30627.76 us     4.374 us        495.755 us
  free_vmap_block                       6993    7011.685 us     1.002 us        159.090 us

AFTER (all new blocks are put to the tail of a free list)

# cat /sys/kernel/debug/tracing/trace_stat/function0
  Function                               Hit    Time            Avg             s^2
  --------                               ---    ----            ---             ---
  vm_map_ram                         2032000    394259.7 us     0.194 us        589395.9 us
  vm_unmap_ram                       2032000    292500.7 us     0.143 us        94181.08 us
  alloc_vmap_area                       7000    31103.11 us     4.443 us        703.225 us
  free_vmap_block                       7000    6750.844 us     0.964 us        119.112 us

SUMMARY:

No surprises here, almost all numbers are the same.

Fixing this fragmentation problem I also did some improvements in a
allocation logic of a new vmap block: occupy block immediately and get
rid of extra search in a free list.

Also I replaced dirty bitmap with min/max dirty range values to make the
logic simpler and slightly faster, since two longs comparison costs
less, than loop thru bitmap.

This patchset raises several questions:

 Q: Think the problem you comments is already known so that I wrote comments
    about it as "it could consume lots of address space through fragmentation".
    Could you tell me about your situation and reason why it should be avoided?
                                                                     Gioh Kim

 A: Indeed, there was a commit 364376383 which adds explicit comment about
    fragmentation.  But fragmentation which is described in this comment caused
    by mixing of long-lived and short-lived objects, when a whole block is pinned
    in memory because some page slots are still in use.  But here I am talking
    about blocks which are free, nobody uses them, and allocator keeps them alive
    forever, continuously allocating new blocks.

 Q: I think that if you put newly allocated block to the tail of a free
    list, below example would results in enormous performance degradation.

    new block: 1MB (256 pages)

    while (iters--) {
      vm_map_ram(3 or something else not dividable for 256) * 85
      vm_unmap_ram(3) * 85
    }

    On every iteration, it needs newly allocated block and it is put to the
    tail of a free list so finding it consumes large amount of time.
                                                                    Joonsoo Kim

 A: Second patch in current patchset gets rid of extra search in a free list,
    so new block will be immediately occupied..

    Also, the scenario above is impossible, cause vm_map_ram allocates virtual
    range in orders, i.e. 2^n.  I.e. passing 3 to vm_map_ram you will allocate
    4 slots in a block and 256 slots (capacity of a block) of course dividable
    on 4, so block will be completely occupied.

    But there is a worst case which we can achieve: each free block has a hole
    equal to order size.

    The maximum size of allocation is 64 pages for 64-bit system
    (if you try to map more, original alloc_vmap_area will be called).

    So the maximum order is 6.  That means that worst case, before allocator
    makes a decision to allocate a new block, is to iterate 7 blocks:

    HEAD
    1st block - has 1  page slot  free (order 0)
    2nd block - has 2  page slots free (order 1)
    3rd block - has 4  page slots free (order 2)
    4th block - has 8  page slots free (order 3)
    5th block - has 16 page slots free (order 4)
    6th block - has 32 page slots free (order 5)
    7th block - has 64 page slots free (order 6)
    TAIL

    So the worst scenario on 64-bit system is that each CPU queue can have 7
    blocks in a free list.

    This can happen only and only if you allocate blocks increasing the order.
    (as I did in the function written in the comment of the first patch)
    This is weird and rare case, but still it is possible.  Afterwards you will
    get 7 blocks in a list.

    All further requests should be placed in a newly allocated block or some
    free slots should be found in a free list.
    Seems it does not look dramatically awful.

This patch (of 3):

If suitable block can't be found, new block is allocated and put into a
head of a free list, so on next iteration this new block will be found
first.

That's bad, because old blocks in a free list will not get a chance to be
fully used, thus fragmentation will grow.

Let's consider this simple example:

 #1 We have one block in a free list which is partially used, and where only
    one page is free:

    HEAD |xxxxxxxxx-| TAIL
                   ^
                   free space for 1 page, order 0

 #2 New allocation request of order 1 (2 pages) comes, new block is allocated
    since we do not have free space to complete this request. New block is put
    into a head of a free list:

    HEAD |----------|xxxxxxxxx-| TAIL

 #3 Two pages were occupied in a new found block:

    HEAD |xx--------|xxxxxxxxx-| TAIL
          ^
          two pages mapped here

 #4 New allocation request of order 0 (1 page) comes.  Block, which was created
    on #2 step, is located at the beginning of a free list, so it will be found
    first:

  HEAD |xxX-------|xxxxxxxxx-| TAIL
          ^                 ^
          page mapped here, but better to use this hole

It is obvious, that it is better to complete request of #4 step using the
old block, where free space is left, because in other case fragmentation
will be highly increased.

But fragmentation is not only the case.  The worst thing is that I can
easily create scenario, when the whole vmalloc space is exhausted by
blocks, which are not used, but already dirty and have several free pages.

Let's consider this function which execution should be pinned to one CPU:

static void exhaust_virtual_space(struct page *pages[16], int iters)
{
        /* Firstly we have to map a big chunk, e.g. 16 pages.
         * Then we have to occupy the remaining space with smaller
         * chunks, i.e. 8 pages. At the end small hole should remain.
         * So at the end of our allocation sequence block looks like
         * this:
         *                XX  big chunk
         * |XXxxxxxxx-|    x  small chunk
         *                 -  hole, which is enough for a small chunk,
         *                    but is not enough for a big chunk
         */
        while (iters--) {
                int i;
                void *vaddr;

                /* Map/unmap big chunk */
                vaddr = vm_map_ram(pages, 16, -1, PAGE_KERNEL);
                vm_unmap_ram(vaddr, 16);

                /* Map/unmap small chunks.
                 *
                 * -1 for hole, which should be left at the end of each block
                 * to keep it partially used, with some free space available */
                for (i = 0; i < (VMAP_BBMAP_BITS - 16) / 8 - 1; i++) {
                        vaddr = vm_map_ram(pages, 8, -1, PAGE_KERNEL);
                        vm_unmap_ram(vaddr, 8);
                }
        }
}

On every iteration new block (1MB of vm area in my case) will be
allocated and then will be occupied, without attempt to resolve small
allocation request using previously allocated blocks in a free list.

In case of random allocation (size should be randomly taken from the
range [1..64] in 64-bit case or [1..32] in 32-bit case) situation is the
same: new blocks continue to appear if maximum possible allocation size
(32 or 64) passed to the allocator, because all remaining blocks in a
free list do not have enough free space to complete this allocation
request.

In summary if new blocks are put into the head of a free list eventually
virtual space will be exhausted.

In current patch I simply put newly allocated block to the tail of a
free list, thus reduce fragmentation, giving a chance to resolve
allocation request using older blocks with possible holes left.

Signed-off-by: Roman Pen <r.peniaev@gmail.com>
Cc: Eric Dumazet <edumazet@google.com>
Acked-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: David Rientjes <rientjes@google.com>
Cc: WANG Chao <chaowang@redhat.com>
Cc: Fabian Frederick <fabf@skynet.be>
Cc: Christoph Lameter <cl@linux.com>
Cc: Gioh Kim <gioh.kim@lge.com>
Cc: Rob Jones <rob.jones@codethink.co.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

hdmi:rk3288/rk3368: polling avi status register instead of delay.

When sending avi introduced by commit 132ad528d034c38bd9b43bb8f08a5c2910a968c2,
we polling avi sending status register until avi is send,  instead of delay 100ms.

Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>

rk3368-p9_818.dts: add suspend config

RK3368 GPU version: Rogue L 0.22
merge 1.4_ED3632227 DDK code.

hdmi:cec: delete maroc DEBUG definaion.

Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>

hdmi:fix edid parse 4096x2160@24Hz error.

Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>

rk3288_mali_t760_driver_r6p0-02rel0_13_x@0

rk-keys: make input registered before key isr and key timer.
fix get pdata NULL pointer error.

Signed-off-by: David Wu <wdc@rock-chips.com>

RK3368 DDR: fix HDMI display abnormal when ddr change freq

add parameter of lcdc type for mcu to fix HDMI display abnormal when do ddr
change freq. it must update bl30 to rk3368bl30_v2.09.bin at the same time.

Signed-off-by: Tang Yun ping <typ@rock-chips.com>

hdmi:cec: Define cec send frame return value.

Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>

hdmi:cec:update driver to match android HDMI CEC HAL.

Android 5.x introduce HDMI CEC, so we need to porting
cec hal and driver to make it work.

Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>

RK312x, VPU: add Reset resource.

support vpu combo cru reset for rk312x.

Signed-off-by: Alpha Lin <alpha.lin@rock-chips.com>

VCODEC: detect hevc resolution to determine the running frequency.

Signed-off-by: Alpha Lin <alpha.lin@rock-chips.com>

rk32: lvds/rgb: fix rgb output when have no lvds_format

If we don't add lvds_format on the display timing, the lvds_format
value may be -1, means 0xffffffff when do register write, that is
wrong and display not works.

Signed-off-by: Mark Yao <mark.yao@rock-chips.com>

dvfs: rockchip: add pvtm_get_temp for pvtm_set_dvfs_table

Signed-off-by: Xiao Feng <xf@rock-chips.com>

rk3288_mali_t760_driver_r6p0-02rel0_12_x@0

dvfs: rockchip: arm pvtm add RK3368_PROCESS_V0

Signed-off-by: Xiao Feng <xf@rock-chips.com>

arm64: rockchip: rk3368: tb-dts: add arm pvtm support

Signed-off-by: Xiao Feng <xf@rock-chips.com>

rk3368: tsadc: set saradc_clk cycle to mcu

Signed-off-by: David Wu <wdc@rock-chips.com>

rk3368: scpi: add interface set cycle for tsadc

Signed-off-by: David Wu <wdc@rock-chips.com>

hdmi:rk3288/rk3368: Reset tmdsclk after configure frame composer regiseter.

It is required to perform a reset tmdsclk action on one of the frame composer
registers changed. Or transport video and audio sample may mistake.

Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>

arm64: rockchip: rk3368: dts: modify the regulator-name of rk818_ldo2

Signed-off-by: Xiao Feng <xf@rock-chips.com>

rk312x, mali_400_driver : modify build_log, upgrade rk_ko_ver to 4.

rk312x, mali_400_driver : fix bug that gpu_clk could not jump to he highest level.

dts: set wifi type and enable pwm1 in rk3288-p977_8846.dts

Signed-off-by: huang zhibao <hzb@rock-chips.com>

hdmi:rk3036/rk3128: support 3D type Frame packing.

Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>

hdmi: reconfigure audio when enable/disable 3D Frame packing mode.

Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>

hdmi:rk3288/rk3368: support 3D type Frame packing.

Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>

camsys_drv: v0.0x21.0

dts: rk3368-p9: battery add and enable power_dc2otg

enable: otg device get power from dc adapter

Signed-off-by: Jianhong Chen <chenjh@rock-chips.com>
Signed-off-by: xushengfei <xsf@rock-chips.com>

power: rk81x-battery: support otg device get power from dc

Signed-off-by: Jianhong Chen <chenjh@rock-chips.com>
Signed-off-by: xushengfei <xsf@rock-chips.com>

power: rk81x-battery: fix power on sec base error

Signed-off-by: Jianhong Chen <chenjh@rock-chips.com>
Signed-off-by: xushengfei <xsf@rock-chips.com>

dvfs: rockchip: print error when clk is disable

Signed-off-by: Xiao Feng <xf@rock-chips.com>