In some cases, the discontinuous biphasic result may not be valid
after sleeping for specified time due to the interrupt preemption.
Therefore, it may be better to use the completion and set the actual
wait time to the 3/2 of the specified delay time.
Change-Id: Ib7ee5f7ceb53c195178e25d745985577fa8a6c4c
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
In some cases, the frequency result may not be valid after sleeping
for specified time due to the interrupt preemption. Therefore, it may
be better to use the completion and set the actual wait time to the
3/2 of the specified delay time.
Change-Id: I5b9879ff9eaaf41ace5534040e0e47ec9bca7cc0
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
If the &rockchip_pwm_biphasic_config.enable is set to false in
continuous biphasic counter mode, &rockchip_pwm_chip.biphasic_config
will be set to NULL after &rockchip_pwm_funcs.set_biphasic.
Without this patch, there may be the null pointer exception.
Fixes: 7a42db27aa ("pwm: rockchip: support for biphasic counter mode")
Change-Id: Ie6fb5e3b1c69ae055720716531ddebb64dbf30bf
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
After completing the initialization of serdes in uboot, enter the kernel
to perform initialization again
Change-Id: I689c30f55d9e259e5adaa95029f7523026cbed0a
Signed-off-by: Zitong Cai <zitong.cai@rock-chips.com>
After completing the initialization of serdes in uboot, enter the kernel
to perform initialization again
Change-Id: Ia603bd2b8892f1647d0c0fa37f38e1422f78a6b3
Signed-off-by: Zitong Cai <zitong.cai@rock-chips.com>
If the cluster sub wins are enabled, there will be POST_BUF_EMPTY
errors after entering the PSR mode, because cluster main wins are
disabled while the sub wins still are active. The patch can help
avoid these unexpected POST_BUF_EMPTY errors.
Change-Id: I3555e0c08c7c4eacf0ace472e3154693c03c6aa9
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
Psr mode can help reduce power consumption when using the mcu panel,
which supports to refresh the image on its own while it remains
unchanged.
Change-Id: Ib9bd1bb472c996277eb374cc9ba1433ce3930d55
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
According to the following commits:
commit 9d0e3cac35 ("drm/atomic: Allow vblank-enabled + self-refresh "disable"")
commit 2bdba9d4a3 ("drm/rockchip: vop: Leave vblank enabled in self-refresh")
It is better to leave vblank enabled after entering the PSR mode, in
order to ensure that the vblank APIs (like DRM_IOCTL_WAIT_VBLANK) can
work in PSR mode. User space is not aware when the display system is
already in PSR mode, so this appears to be an API violation.
Without this patch, there may be a warning according to the following
check in drivers/gpu/drm/drm_atomic_helper.c:
static void
disable_outputs(struct drm_device *dev, struct drm_atomic_state *old_state)
{
......
ret = drm_crtc_vblank_get(crtc);
/*
* Self-refresh is not a true "disable"; ensure vblank remains
* enabled.
*/
if (new_crtc_state->self_refresh_active)
WARN_ONCE(ret != 0,
"driver disabled vblank in self-refresh\n");
else
WARN_ONCE(ret != -EINVAL,
"driver forgot to call drm_crtc_vblank_off()\n");
if (ret == 0)
drm_crtc_vblank_put(crtc);
......
}
Change-Id: I95ee15864c1dfa1045c41c7a9ed2985bb6107f2b
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
According to the following commits:
commit 9d0e3cac35 ("drm/atomic: Allow vblank-enabled + self-refresh "disable"")
commit 2bdba9d4a3 ("drm/rockchip: vop: Leave vblank enabled in self-refresh")
It is better to leave vblank enabled after entering the PSR mode, in
order to ensure that the vblank APIs (like DRM_IOCTL_WAIT_VBLANK) can
work in PSR mode. User space is not aware when the display system is
already in PSR mode, so this appears to be an API violation.
Without this patch, there may be a warning according to the following
check in drivers/gpu/drm/drm_atomic_helper.c:
static void
disable_outputs(struct drm_device *dev, struct drm_atomic_state *old_state)
{
......
ret = drm_crtc_vblank_get(crtc);
/*
* Self-refresh is not a true "disable"; ensure vblank remains
* enabled.
*/
if (new_crtc_state->self_refresh_active)
WARN_ONCE(ret != 0,
"driver disabled vblank in self-refresh\n");
else
WARN_ONCE(ret != -EINVAL,
"driver forgot to call drm_crtc_vblank_off()\n");
if (ret == 0)
drm_crtc_vblank_put(crtc);
......
}
Change-Id: Ide735636ab53fd6977de5034b8cfc4c8341220af
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
The module NE160QAM-NX1 support eDP v1.4b with the following
features:
- Support resolutions 3840x2400p60 and 3840x2400p120
- 4 lanes eDP interface with 8.1Gbps link rates
- DPCD v1.4
- PSR(Panel self Refresh)
- DSC(Display Stream Compression)
Change-Id: I41361dc5500cd35234bfdc8436a50e3117c6fba2
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
The module NE160QAM-NX1 support eDP v1.4b with the following
features:
- Support resolutions 3840x2400p60 and 3840x2400p120
- 4 lanes eDP interface with 8.1Gbps link rates
- DPCD v1.4
- PSR(Panel self Refresh)
- DSC(Display Stream Compression)
Change-Id: Ibd0472e00cef827900ef78320ef08fc372e265d3
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
The &link_train.link_rate and &link_train.lane_count are used as the
max_link_rate and max_lane_count to check the bandwidth limitation
, select output format and so on. However, they both also are used as
the actual link_rate and lane_count for the eDP controller and phy.
So we add &link_train.max_link_rate and &link_train.max_lane_count
in order to avoid the confusion in the use of above variables.
On the other hand, some unexpected errors will occur without this
patch in some cases.
When I test the PSR function of eDP panel module NE160QAM-NX1, the
link rate will be set to the 8.1G, which is the max supported link
rate of this module, after exiting the PSR state, but it should be
5.4G corresponding to 3840x2400p60 resolution.
analogix_dp_detect(): set the &link_train.link_rate to 8.1G
-> analogix_dp_fast_link_train():
use the &link_train.link_rate as the previous link config
-> analogix_dp_set_link_bandwidth()
-> phy_configure():
error: invalid link_rate config 8.1G
Change-Id: I1a4ae3c1eb308c9e0d25fb7736de52336ea7f880
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
* commit '1220a99380b8d65488bec37f46398785ba605203': (45 commits)
media: rockchip: isp: uv write on-off if black and white switch for isp35
media: rockchip: isp: fix w3a with aiisp for isp35
drm/bridge: synopsys: dw-hdmi-qp: Get uboot color format from avi regs in dsc mode
drm/bridge: synopsys: dw-hdmi-qp: Clear edid property when hdmi plug out
arm64: dts: rockchip: rv1126b: Add power domain for vop/mipi_dphy
soc: rockchip: power-domain: Add protect for rv1126b pd npu and vdo
arm64: dts: rockchip: rv1126b: add optee dts
ARM: configs: rv1126b-evb: enable icm42670
drm/rockchip: vop2: fix the logic error to control the sharp en
drm/rockchip: vop2: add more log for debug
drm/rockchip: vop2: correctly get old/new vcstate
drm/rockchip: vop2: init vp->output_if for logo state
ASoC: rockchip: pdm: set pin as pdm function when record
arm64: dts: rockchip: rv1126b-evb2-v10: Adapt the PMU IO states for the sleep mode
media: i2c: gc8613: add 3840x2160 30fps linear mode setting
arm64: dts: rockchip: rv1126b: rkrng: add clock setting
dt-bindings: clock: rv1126b: fix HCLK_RKRNG_S_NS ID
media: rockchip: fec: update procfs info
mfd: display-serdes: Remove the loading of serdes child devices that are not enabled by DTS
media: rockchip: vpss: support online FBC format input
...
Change-Id: I0e7f5df8201dfd7e5d4cf6786a2577f3810cb708
RK3588/RK3576 hdmi color format setting and dsc mode setting are
the same mask in the same register. If dsc is enabled for hdmi in
uboot, what color is hdmi output in uboot that cannot be obtained
from this register in kernel.
Since hdmi in dsc mode always sends avi infoframe, color format
of hdmi output in uboot can be read from the avi register.
Change-Id: I68157455342302338370feb9176b46e2051b4f01
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
If edid property is not cleared when hdmi plug out, edid value
maybe keep previous sink's when the hdmi is connected to another
sink.
Change-Id: I8d06de17040573de4ef4706183bd7b46c4002ae4
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
