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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
