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>

ASoC: rockchip: i2s: add pcm transfer mode support.

usage: add i2s dts property "rockchip,xfer-mode"

rockchip,xfer-mode = <0>: i2s transfer mode.
rockchip,xfer-mode = <1>: pcm transfer mode.

if not define, use i2s transfer mode default.
pcm transfer mode is usually used for bt/modem voice.

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

hdmi:rk3288:enable supporting 10bit output.

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

hdmi:use 30bit lcdc interface when output 10bit mode.

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

rk fb: add YUV420 10bit output mode for next soc

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

hdmi: hdmi_submit_work function support synchronous operation.

If hdmi_submit_work work in synchronous mode, the malloced delayed_work
is free by caller, not by hdmi_work_queue, to prevent delayed_work is
free before flush_delayed_work fucntion is executed.

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

dts:arm:rk3288-box: ddr frequency set to 533 when playing 4K video.

If we playing 4K60Hz video, and there are more than two ui layer which
is continuously refreshing, bandwith will be not enougth under ddr 456MHz.

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

hdmi:rk3288/rk3368: enable PHY SVSRET mode while in power-down mode.

While in power-down mode, the HDMI Tx PHY can be additionally set in
a lower mode of consumption by enabling the SVSRET mode, achieved by
asserting the SVSRET_MODEZ signal low.

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

hdmi:rk3288/rk3368: set controller register in uboot logo mode.

EDID data readed in uboot and kernel may be different, and hdmi
output color mode is different in uboot and kernel: uboot output
RGB when EDID is wrong and kernel output YCbCr with right EDID.
But avi infomation and controller register is not set in kernel,
so the picture is wrong. Now fix this bug.

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

rk3288: clk: support clk_ddr round rate.

support clk_ddr round and set rate.
slove the develop-3.10-next merge missing some function.

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

fix rga_ioctl return error

Signed-off-by: Shengqin.Zhang <zsq@rock-chips.com>

hdmi: use dps->lock replace of hdmi->lock.

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

EDP:RK3288: add debugfs node for psr function.

    enter the drectory:debugfs/edp.
    command as follows:
    echo 0 > psr : disable psr
    echo 1 > psr : config and enable psr
    echo 2 > psr : sink get in  psr inactive
    echo 3 > psr : sink get in  psr state2
    echo 4 > psr : sink get in  psr state3
    echo 5 > psr : open phy 4 lanes
    echo 6 > psr : close phy 4 lanes
Signed-off-by: linwei <buluo.lin@rock-chips.com>
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>

rk_fb: rk3288: fix win2 disable iommu crash.

uvc: support the query of iommu_enabled

bcmdhd wifi: support ap6356 nvram auto recognize

eDP:rk3288:ignore grf probe error when probe.

rockhip,grf node is not exist on rk3288,  we
need to ignore grf probe error.

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

eDP:RK3288 check format for rk32_dp.c rk32_dp.h

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

rk3288: clk: slove make warning for clk-ops.c

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

rk3288: clk: support clk_vop set 594M.

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

rk3288: clk: support aclk_vio 594M.

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

rk: pmic: rk818: add interface to set ldo sleep state.

add interface to set ldo sleep state,
which hope can dynamically modify the ldo sleep state.

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

VPU: pmu idle request before cru operation.

pmu idle request before cru operation to ensure the hardware
don't be reset during runing. without this hardware maybe hang
up for bus access failure.

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

RK3288 VPU: add cru reset resource.

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

rk3x:pmic: rk818:enable hdmi5v in sleep mode and improve buck efficiency

enable hdmi5v in sleep mode for low power.
improve buck efficiency for low power.

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

MIPI: fix the first wake-up not display bug.

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

power: rk81x battery: use get_monotonic_boottime to get system run time

local_clock will lose the suspend time, so we use get_monotonic_boottime instead

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

power: rk81x-battery: modify low power check threshold voltage

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

power: rk81x-battery: add calc seconds availability check

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

power: rk81x-battery: add debug message dump limit

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

power: rk81x-battery: optimize zero discharge algorithm

avoid display_soc to be initialed in some case which makes dsoc
drop too quick

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

power: rk81x-battery: get charger type by usb notifier instead of polling

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

dts: rk3368-p9_818: disable vcc_codec when system sleep.

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

hdmi:rk3036/rk3128: fix picture flicker error when setting audio.

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

hdmi:rk3288/rk3368: modify avi colorimetry information according to input colorimetry.

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

hdmi: support parse and modify colorimetry.

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

fix rga2 3368 first proc scale bug

Signed-off-by: Shengqin.Zhang <zsq@rock-chips.com>

fix rga2 soft reset may cause rga status uncorrect

Signed-off-by: Shengqin.Zhang <zsq@rock-chips.com>

fix rga miss flush cmd reg to DDR bug

Signed-off-by: Shengqin.Zhang <zsq@rock-chips.com>

ASoC: es8316: reinit codec when resume from deep sleep.

because codec power will be cut off when enter deep sleep.
so need reinit codec when resume.

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

ASoC: rockchip: i2s: move pinctrl_pm_* to suspend/resume.

some codec initializtion depends on i2s's mclk/lrck, when codec enter
deep sleep, codec power loss, then codec resume and reinit
codec logic which need mclk/lrck, if these clk is not ready, codec will
work abnormally.

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

hdmi: move show sink info to debug node.

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

hdmi: modify debug string mode.

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

hdmi: mute output before disabled or suspended.

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

Drivers: TP: disable vcc_tp when gt9xx in suspend mode

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

rk3368: rk3368-p9_818.dts: set vcc_tp sleep mode to disabled

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

PMIC:rk818.dtsi: remove rk818_reg_ldo2 aways-on,
then we can disable it during OS is running

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

RK3368: add vpu cru reset resource.

Add cru reset resource according to RESET CONTROLLER.

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

VPU: add cru reset support.

This depend on RESET_CONTROLLER enable on kernel.

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

mmc: rk_sdmmc: enhance recovery flow

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

dts: rockchip: add cru regmap refnode for mmc

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

direct-io: only inc/dec inode->i_dio_count for file systems

do_blockdev_direct_IO() increments and decrements the inode
->i_dio_count for each IO operation. It does this to protect against
truncate of a file. Block devices don't need this sort of protection.

For a capable multiqueue setup, this atomic int is the only shared
state between applications accessing the device for O_DIRECT, and it
presents a scaling wall for that. In my testing, as much as 30% of
system time is spent incrementing and decrementing this value. A mixed
read/write workload improved from ~2.5M IOPS to ~9.6M IOPS, with
better latencies too. Before:

clat percentiles (usec):
|  1.00th=[   33],  5.00th=[   34], 10.00th=[   34], 20.00th=[   34],
| 30.00th=[   34], 40.00th=[   34], 50.00th=[   35], 60.00th=[   35],
| 70.00th=[   35], 80.00th=[   35], 90.00th=[   37], 95.00th=[   80],
| 99.00th=[   98], 99.50th=[  151], 99.90th=[  155], 99.95th=[  155],
| 99.99th=[  165]

After:

clat percentiles (usec):
|  1.00th=[   95],  5.00th=[  108], 10.00th=[  129], 20.00th=[  149],
| 30.00th=[  155], 40.00th=[  161], 50.00th=[  167], 60.00th=[  171],
| 70.00th=[  177], 80.00th=[  185], 90.00th=[  201], 95.00th=[  270],
| 99.00th=[  390], 99.50th=[  398], 99.90th=[  418], 99.95th=[  422],
| 99.99th=[  438]

In other setups, Robert Elliott reported seeing good performance
improvements:

https://lkml.org/lkml/2015/4/3/557

The more applications accessing the device, the worse it gets.

Add a new direct-io flags, DIO_SKIP_DIO_COUNT, which tells
do_blockdev_direct_IO() that it need not worry about incrementing
or decrementing the inode i_dio_count for this caller.

Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Theodore Ts'o <tytso@mit.edu>
Cc: Elliott, Robert (Server Storage) <elliott@hp.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Tested-and-Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>

defconfig: rockchip: enable CONFIG_MMC_DW_SKIP_CACHE_OP

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

fs: direct-io: convert rw from READ to KERNEL_READ

KERNEL_READ equal READ puls REQ_KERNEL, which indicates
this brq comes from direct-io. Any block-layer devices who
care this req type can get it now.

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

mmc: rk_sdmmc: add MMC_DW_SKIP_CACHE_OP for data manipulation

Direct IO of filesystem  had recursive searched and map the addr
itself, so mmc drivers can avoid to do the same ops in order to
improve throughput. We got 30% improvement for 4KB bs packet test.

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

arm64: dma-mapping: conditional skip map_sg by attrs

Add if statement(DMA_ATTR_SKIP_CPU_SYNC) for __swiotlb_map_sg_attrs
to skip invalidating each sg element

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

 hdmi:rk3368/rk3288: modify phy termination resistance.

        Set single-ended source termination resistance
        to 100ohm for HDMI1.4 and 50ohm for HDMI2.0.

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

hdmi:rk3368/rk3288: set color format in avi to RGB before mute output.

        For some sink, it will random recognize YCbCr as RGB when swithing
        hdmi format, picture will covered with purple. If we set color
        fomat in avi to RGB and reset avi to YCbCr, picture will be ok. So
        we set avi to RGB before mute ouput when switching hdmi format.

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

dts:sdmmc: slow down sdmmc frequence to 37.5MHz for SDK board

SDK board sdmmc can't run 50MHz, otherwise SD initialising will return error.
log as below. slow down sdmmc frequence to 37.5MHz can fix it.

<4>[  802.611901]  [0:    kworker/0:2:  644] rk_sdmmc: BOOT   The card is inserted.  ===!!!!!!==[mmc1]
<6>[  802.838728]  [0:  kworker/u16:0:    6] mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 400000Hz, actual 3
96825HZ div = 63)
<4>[  802.838858]  [0:  kworker/u16:0:    6] rk_sdmmc: BOOT dw_mci_setup_bus: argue clk_mmc workaround out 800000Hz for
init[mmc1]
<6>[  802.990527]  [0:  kworker/u16:0:    6] mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 50000000Hz, actual
50000000HZ div = 0)
<4>[  802.990671]  [0:  kworker/u16:0:    6] rk_sdmmc: BOOT dw_mci_setup_bus: argue clk_mmc workaround out normal clock
[mmc1]
<3>[  802.996461]  [0:  kworker/u16:0:    6] mmc1: error -84 whilst initialising SD card

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

tve:rk1000: set default cvbd mode to PAL.

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

dts:rk3368-box: enable uboot logo

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

rfkill-wlan: repair vref pmu ctrl problem