change needed min buffers of stream to 0, because we allocate dummy
buffer in advance.
Change-Id: Ib7647983b495c11dc18151b3c1f8856c49496c3a
Signed-off-by: Hu Kejun <william.hu@rock-chips.com>
The video BIST function of the DP_TX generates arbitrary video formats
internally according to the specified format configuration and selection.
These BIST video formats simplify DP_TX debugging.
Change-Id: Ia019c8f40fdd4ebea3e5250be8e2c15540481a6c
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
Dmac pl330 adds src_interlace_size of dma_slave_config rxconf.
If rxconf is local variable, src_interlace_size may be non zero,
which causes wrong process.
Fixes: ddd2e87ad4 ("dmaengine: pl330: add support for interlace size config")
Change-Id: Ib301c7ca4a1175bafd0631cb4deea4baa60eebc7
Signed-off-by: Huibin Hong <huibin.hong@rock-chips.com>
RK3308B is a enhanced variant of RK3308 with more flexible
iomux and peripherals(for example, RK3308B has 12 pwms, but
RK3308 has 4).
The CHIP_ID is stored in GRF_CHIP_ID:
RK3308: 0xcea (3306 in decimal)
RK3308B: 0x3308
Change-Id: I8f675656c012bdedb43043f5dbeea8bd11ea4ded
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
As npll rate may be changed according to vopl dclk rate on px30.
Change-Id: I4abc042b49ee06436ba5d69dc8adfa9460da37f7
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
NPLL should provide clock for vopl dclk on px30, and its rate will be
changed according to vopl dclk rate, so GPU can't use npll as parent
on px30.
Change-Id: Ib2c8c57020405bcd14070dcd7bc71cbfe18230e3
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
make me more easily to check the mapping.
Also fix some compiler warnings.
Change-Id: Ic28f6ce54b4dcd0c4a9d9543939c5f5e013136fc
Signed-off-by: Randy Li <randy.li@rock-chips.com>
It make all kernel version use the same ioctl defines.
The compat ioctl doesn't support the customer ioctl of the
mpp device.
Change-Id: I018ec2eb48cd2ca4e211da7137781771b33bda15
Signed-off-by: Randy Li <randy.li@rock-chips.com>
when two dvp sensor connect to rkisp1, only one sensor can connect to sink
pad, another sensor connect to sink params pad.
Change-Id: I6cc9e6db3ad074c82c15a9cc642330ece6997d09
Signed-off-by: Hu Kejun <william.hu@rock-chips.com>
The fiq_tty_proc_show can be called even when fiq is not enabled in dts,
which would cause crash.
Add sanity check to avoid that.
Change-Id: I69d34718f91813aed14c542901060e4fd68b818b
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
When I tested DP function on excavator, I found that commit 1bf7191033de
("BACKPORT: FROMLIST: phy: rockchip-typec: support variable phy config value"),
which change pll settings, but it does not work as expected on excavator board.
With this patch series, DP works well on excavator and roc.
Change-Id: I48fe0c51e322369d1aff352f4ebaf1096f264834
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
The innoslicon GF22FDX MIPI D-PHY integrates a MIPI 1.2
compatible PHY that supports up to 2.5Gbps high speed data
transmitter, plus a MIPI low-power low speed transceiver
that support data transfer in the bi-directional mode.
The IP supports the full specifications described in the
D-PHY spec 1.2. The D-PHY is built in with a standard
digital interface to talk to any third party host controller.
Change-Id: Iad7b9dc8fedaa1a5741830e9c02a593f544c2423
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
rk1808 have vop lite and vop raw:
1. vop lite: support win1 for display, vop->dsi tx->dphy->lcd.
2. vop raw: transfer data from ddr to csi tx.
Change-Id: I11229b5e61e66e72e4228e7e0ac966f1f85cb49f
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
This algorithm defaults to choosing higher pin config over
lower ones in order to prefer multi-function if desired.
NAME | SIGNALING | OUTPUT TYPE | MULTI-FUNCTION | PIN CONFIG
-------------------------------------------------------------
A | USB G2 | ? | no | 00_0001
B | USB G2 | ? | yes | 00_0010
C | DP | CONVERTED | no | 00_0100
D | PD | CONVERTED | yes | 00_1000
E | DP | DP | no | 01_0000
F | PD | DP | yes | 10_0000
if UFP has NOT asserted multi-function preferred code masks away
B/D/F leaving only A/C/E. For single-output dongles that should
leave only one possible pin config depending on whether its a
converter DP->(VGA|HDMI) or DP output. If UFP is a USB-C receptacle
it may assert C/D/E/F. The DFP USB-C receptacle must always choose
C/D in those cases.
Change-Id: I5594d39a302f27e2d72259f6a18308488d4fa47c
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
DP firmware uses fixed phy config values to do training, but some
boards need to adjust these values to fit for their unique hardware
design. So get phy config values from dts and use software link training
instead of relying on firmware, if software training fail, keep firmware
training as a fallback if sw training fails.
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Signed-off-by: Lin Huang <hl@rock-chips.com>
(am from https://patchwork.kernel.org/patch/10420469/)
Conflicts:
drivers/gpu/drm/rockchip/cdn-dp-reg.h
[Context - non-upstream HDCP stuff]
BUG=b:72006974
TEST=DP can display on Dru
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/985573
Tested-by: Lin Huang <hl@rock-chips.com>
Reviewed-by: Sean Paul <seanpaul@google.com>
Change-Id: I402c5fd2c83979cee67856e66311d2b1b9c6f774
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
This patch transitions our rockchip driver to using the upstream
content_protection_property (located in drm_connector) as opposed to the
downstream version that's in mode_config.
In addition to the new location of the property, this patch also makes
HDCP enablement work via atomic commits in addition to the legacy
setproperty ioctl.
The trickiest part of making this work is ensuring we keep the
connector->state->content_protection value in sync with what the
hardware is doing. We're only allowed to change this value in
atomic_check (which we do for certain transitions), however we have to
be careful when updating it outside of atomic_check, this requires
locks. In order to update the property without races, we need a new property
worker whose job is to acquire the connection and dp locks and update the state.
It's not possible to do this without the dedicated worker since the hdcp event
worker doesn't hold the connection mutex, and can't acquire it since we
synchronously cancel it while holding the connection mutex elsewhere. Sigh.
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/864343
Commit-Ready: Sean Paul <seanpaul@google.com>
Tested-by: Sean Paul <seanpaul@google.com>
Reviewed-by: Sean Paul <seanpaul@google.com>
Change-Id: I22d2592096866d2346bc9b48f48e66e845a173f8
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
This patch adds a new optional connector property to allow userspace to enable
protection over the content it is displaying. This will typically be implemented
by the driver using HDCP.
The property is a tri-state with the following values:
- OFF: Self explanatory, no content protection
- DESIRED: Userspace requests that the driver enable protection
- ENABLED: Once the driver has authenticated the link, it sets this value
The driver is responsible for downgrading ENABLED to DESIRED if the link becomes
unprotected. The driver should also maintain the desiredness of protection
across hotplug/dpms/suspend.
If this looks familiar, I posted [1] this 3 years ago. We have been using this
in ChromeOS across exynos, mediatek, and rockchip over that time.
Changes in v2:
- Pimp kerneldoc for content_protection_property (Daniel)
- Drop sysfs attribute
Changes in v3:
- None
Changes in v4:
- Changed kerneldoc to recommend userspace polling (Daniel)
- Changed kerneldoc to briefly describe how to attach the property (Daniel)
Changes in v5:
- checkpatch whitespace noise
- Change DRM_MODE_CONTENT_PROTECTION_OFF to DRM_MODE_CONTENT_PROTECTION_UNDESIRED
Changes in v6:
- None
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
[1] https://lists.freedesktop.org/archives/dri-devel/2014-December/073336.html
Link: https://patchwork.freedesktop.org/patch/msgid/20180108195545.218615-4-seanpaul@chromium.org
(cherry picked from commit 24557865c8)
Signed-off-by: Sean Paul <seanpaul@chromium.org>
[downstream changes]
- Fixed some conflicts in comments
- Remove duplicate definition for drm_get_content_protection_name
Change-Id: I825b4863bea715434cb8f76f99fdf6e3fca74a60
Reviewed-on: https://chromium-review.googlesource.com/849079
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Sean Paul <seanpaul@google.com>
Reviewed-by: Sean Paul <seanpaul@google.com>
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
Enabling HDCP on plug/re-plug when already desired was flakey. However,
toggling the property always worked when already plugged in. It seems
like the hardware wants to be explicitly disabled before being enabled.
This patch adds the disable with a short wait before kicking off HDCP.
BUG=b:63816472
TEST=Two cases:
1)
- Boot device with dongle unplugged
- Mark HDCP as desired
- Plug HDMI + dongle
- Ensure HDCP is enabled
2)
- Plug HDMI + dongle
- Mark HDCP as desired, wait for it to enable
- Unplug HDMI from dongle
- Replug HDMI to dongle
- Ensure HDCP is enabled
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/687802
Commit-Ready: Sean Paul <seanpaul@google.com>
Tested-by: Sean Paul <seanpaul@google.com>
Reviewed-by: Kristian H. Kristensen <hoegsberg@chromium.org>
Change-Id: I7c1dfd93bad60483d04525b79c6f75b728096ed4
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
This patch adds new calls for HDCP disable/enable such that HDCP is
properly disabled/restored across hotplugs (both dongle and cable) and
power on/off.
BUG=b:63816472
TEST=Use hdcp test script below:
attr=/sys/class/drm/card1-DP-1/content_protection
printf "Testing HDCP...\n"
while [ 1 ]; do
printf "\rSetting state to desired... "
echo "Desired" > $attr
sleep $(perl -e 'printf("%.1f\n", rand() * 3)')
printf "\rSetting state to undesired..."
echo "Undesired" > $attr
sleep $(perl -e 'printf("%.1f\n", rand() * 3)')
done
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/657941
Commit-Ready: Sean Paul <seanpaul@google.com>
Tested-by: Sean Paul <seanpaul@google.com>
Reviewed-by: Kristian H. Kristensen <hoegsberg@chromium.org>
Change-Id: I4bcc7decc43f7b648054d841efbade7315e785fe
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
The rest of the driver uses DRM_DEV_*, so too should the hdcp functions.
This patch also prints error messages when enable/disable fails, as well
as info messages when hdcp is successfully enabled/disabled.
BUG=b:63816472
TEST=Enable hdcp, log messages are prefixed with drm goo
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/657940
Commit-Ready: Sean Paul <seanpaul@google.com>
Tested-by: Sean Paul <seanpaul@google.com>
Reviewed-by: Kristian H. Kristensen <hoegsberg@chromium.org>
Change-Id: I2503ba4ce6839bb8d9db77ae88446da4888732d5
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
A couple of things to reduce the races during hdcp enable/disable:
- Cancel any active workers currently transition
- Hold lock while disabling hdcp
BUG=b:64438996
TEST=Run the following script, ensure sequencing is correct:
attr=/sys/class/drm/card1-DP-1/content_protection
printf "Testing HDCP...\n"
while [ 1 ]; do
printf "\rSetting state to desired... "
echo "Desired" > $attr
sleep $(perl -e 'printf("%.1f\n", rand() * 3)')
printf "\rSetting state to undesired..."
echo "Undesired" > $attr
sleep $(perl -e 'printf("%.1f\n", rand() * 3)')
done
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/657938
Commit-Ready: Sean Paul <seanpaul@google.com>
Tested-by: Sean Paul <seanpaul@google.com>
Reviewed-by: Kristian H. Kristensen <hoegsberg@chromium.org>
Change-Id: I535b23ffb22eba251a595dcdc4c204de80765414
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
