For simulation aux client, the virtual channel pyaload id can't
send by sideband MSG. In this case, the MST device often config
a fix payload id. It need DPTX also config fix payload id to
match the MST device.
Change-Id: I49148e92a80091a50a5b1f44496430f39d9c1aee
Signed-off-by: Zhang Yubing <yubing.zhang@rock-chips.com>
some MST-capable device may not support Messaging AUX Client.
In this case, sideband MSG can't be transferred between DPTX
and the MST device. A solution is to simulate a Messaging AUX
client in MST device side to deal with sideband MSG.
Change-Id: I7c68f6d0bd88501c4e19097e3a1f9a9fabcf2698
Signed-off-by: Zhang Yubing <yubing.zhang@rock-chips.com>
Once upstream is merged, this patch can be dropped.
also for line CONFIG_NO_GKI
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>
Change-Id: I83f5a08e93010741c26ec044f70b388a50e6c7a9
Once upstream is merged, this patch can be dropped.
also for line CONFIG_NO_GKI
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>
Change-Id: I2b0fc69aa6673e46dcd65e0369ab4353e7c4f9fc
1. open spi1 dev
2. change spi codec to dummy codec
3. remove es8388 sound
This patch keeps the vehicle sound to be "car-rk3308-sound" since the
audio HAL use it fixed.
Change-Id: I6a968e09f548cffa64088bfba0c7c266f3727146
Signed-off-by: Zheng zhiqi <looper.zheng@rock-chips.com>
Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
When dmabuf cache disable:
1.move most recently used link node to link tail,
instead of calculate oldest ktime when buffer full.
2.For those buffer import by ioctl MPP_CMD_TRANS_FD_TO_IOVA,
move to static_list instead of used_list,
and don't increase extra kref,
so that it will release when user space call
ioctl MPP_CMD_RELEASE_FD.
Change-Id: I38f209c24f6cc7e831338e2417050e3ef39226f9
Signed-off-by: Chandler Chen <chandler.chen@rock-chips.com>
enable multiple raw sensor link to isp depend on config MULTI_SENSOR_LINK_TO_ISP
Signed-off-by: Cai Wenzhong <cwz@rock-chips.com>
Change-Id: I52a0ca4f1c6cb26a43c95b5d3a41df2b4f351ad4
As described in:
https://patchwork.freedesktop.org/patch/msgid/20190228210939.83386-2-sean@poorly.run
From the driver's perspective, this works like a regular disable/enable
cycle. The driver need only check the 'psr_transition' state in
connector_state and keep the panel turned on when in .disable(), while
everything else will cycle off as normal. If drivers want more control,
they can use the psr_transition state to enter a low-power state to
minimize PSR exit time.
While this carries the PSR moniker, it is not specific to the
DisplayPort technology. This can be used for power savings
with other types of self refresh, such as MIPI command mode.
Change-Id: I80799c7f1356645e50dae98159591dde6aa5abff
Signed-off-by: Guochun Huang <hero.huang@rock-chips.com>
if the mode of the PHY is not set in .loader_protect helper,
when entering sleep mode for the first time bring up with
display logo, the PHY will not be able to shut down completely
and accurately because it does not know in which mode it is
operating, resulting in some power consumption.
Change-Id: If5606c24fd2a542936cdb2f1c3d4e380d6c3889a
Signed-off-by: Guochun Huang <hero.huang@rock-chips.com>
Usperspace not commit new frame for long time will triggle
driver enter psr mode, If userspace directly close display
at next time and without any new frame commit, driver will
not exit psr, at this case we need to recover aclk here
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
Change-Id: I4bf78c5fa12ca7fa557d8e82d92427b0f849f2eb
At RK356X/RK3588/RK3562/RK3528 linear 10bit yuv format actual_w should
align as 4 pixel, from RK3576 linear 10bit yuv format actual_w should
align as 2 pixel.
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
Change-Id: I719f59574442628f2ed2410d6ca20194cf6f580d
Reset the enc core will clear the reference info of the dual-core
parallel encoding, which will cause parallel enc err.
So use another way to workaround.
Change-Id: I3ef8ae3397687929c529b40f21cb34ea3d1c327f
Signed-off-by: Yandong Lin <yandong.lin@rock-chips.com>
Fixes: d420d65bec ("drm/rockchip: dsi2: optimize drive probe process")
rockchip drm will Registers a new aggregate driver consisting of the
components added to @match by calling one of the component_match_add()
functions. Once all components in @match are available, it will be assembled
by calling &component_master_ops.bind(rockchip_drm_ops.rockchip_drm_bind)
from @ops.
if the dsi->slave is not added into component, the binding status of
the device under the display subsystem becomes abnormal as follows:
cat /sys/kernel/debug/device_component/display-subsystem
aggregate_device name status
-------------------------------------------------------------
display-subsystem not bound
device name status
-------------------------------------------------------------
fdd90000.vop not bound
fde20000.dsi not bound
(unknown) not registered
Change-Id: I5739f06b4ef65f0b8de8f3394f4e811abe31a22c
Signed-off-by: Guochun Huang <hero.huang@rock-chips.com>
commit f342de4e2f33e0e39165d8639387aa6c19dff660 upstream.
This reverts commit e0abdadcc6.
core.c:nf_hook_slow assumes that the upper 16 bits of NF_DROP
verdicts contain a valid errno, i.e. -EPERM, -EHOSTUNREACH or similar,
or 0.
Due to the reverted commit, its possible to provide a positive
value, e.g. NF_ACCEPT (1), which results in use-after-free.
Its not clear to me why this commit was made.
NF_QUEUE is not used by nftables; "queue" rules in nftables
will result in use of "nft_queue" expression.
If we later need to allow specifiying errno values from userspace
(do not know why), this has to call NF_DROP_GETERR and check that
"err <= 0" holds true.
Bug: 323034288
Fixes: e0abdadcc6 ("netfilter: nf_tables: accept QUEUE/DROP verdict parameters")
Cc: stable@vger.kernel.org
Reported-by: Notselwyn <notselwyn@pwning.tech>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 8e34430e33)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: Ie6c699cea6f92cd4a7642f196d5f5cbffe268a6d
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
