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>
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>
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>
The Content Protection properties in 4.4 used v2 of the upstream
patches, but chrome (and upstream) prefer v1. This patch removes the ksv
property and reinstates the ENABLED enum value to the content protection
property.
BUG=b:63816472
TEST=Watch protected content on external display, ensure CP is
enabled/disabled properly by chrome
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/687800
Commit-Ready: Sean Paul <seanpaul@google.com>
Tested-by: Sean Paul <seanpaul@google.com>
Reviewed-by: Kristian H. Kristensen <hoegsberg@chromium.org>
Change-Id: I38cecce2d15b4d4b1ce95ef0e572a08f1bc97131
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
I've seen this:
sysfs: cannot create duplicate filename '/devices/platform/fec00000.dp/hdcp_key'
Presumably because component_add() can -EPROBE_DEFER.
At any rate, we shouldn't leave the sysfs file hanging around. Clean it
up on probe failure, and on removal.
BUG=b:36566733
TEST=boot
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/458836
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Change-Id: Ic10f45c0d67cfcc41ab89af108a78f641f424872
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
Implement HDCP 1.4 authentication function for DP driver.
First, userspace write HDCP cipher to driver via "hdcp_key" sysfs node,
it contains ksv and device private key. DP connector object has a
"Content Proection" property which it's 'Undesired' default. Userspace
set it to 'Desired' as a HDCP authentication request, and it will be set
to 'Enabled' once HDCP authenticated.
BUG=chrome-os-partner:56883
TEST=WITH HDCP KEY SITUATION:
1.flash encrypt key to vpd area, and reboot chromebook.
$ vpd -O; vpd -s hdcp_key_v1_4=something...;dump_vpd_log
--force;
2.write key to DP driver.
$ grep hdcp_key /var/cache/vpd/full-v2.txt | cut -s -d \" -f 4 |
tr -d "\n" > /sys/devices/platform/fec00000.dp/hdcp_key
3.set "Content Protection" property to 'Desired'
$ proptest 36 connector 23 1
4.if the HDCP 1.4 authenticated, the 'Content Proection' will be
changed to 'Enabled'
Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/403975
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Change-Id: I58f11535dd68d9517a3c7b0b9a61ed9fa6d9a1c0
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
Although this property value have been deleted from the latest
FROMLIST version (CL:266854), but the chromeos would want driver
to report the property to "Enabled" when hardware HDCP have been
enabled successfully, so let's add this back.
BUG=chrome-os-partner:56883
TEST=None
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/403974
Reviewed-by: Sean Paul <seanpaul@google.com>
Change-Id: Icc52d4a83ac434e898be1190cf934ed8333e78bf
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
Add new standard connector properties to track whether content protection
(ex: hdcp) is desired by userspace. There are two properties involved,
"Content Protection" and "Content Protection KSV".
The "Content Protection" property allows userspace to request protection
on a connector. Set "Desired" to enable, "Undesired" to disable.
The "Content Protection KSV" property reflects the current state of
protection. If the KSV is 0, the connection is not protected. Once the
driver has enabled protection, it will update the the value with the KSV
(or similarly unique identifier, if not using HDCP) of the first-hop
device (sink or repeater).
(am from https://patchwork.kernel.org/patch/5439871/)
BUG=chrome-os-partner:56883
TEST=Tested on kevin, ensured the sysfs file showed up, and
reflected the correct
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/403973
Reviewed-by: Sean Paul <seanpaul@google.com>
Change-Id: I6bef13729f77de6e37d2da5e12fc69f810a2e286
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
Provide the "hdcp_key" debug node in sysfs, so that userspace can pass
the legitimate HDCP key to driver.
For ATF security, we should transmit HDCP key data via smc argument one
by one.
Moreover, driver request one page SRAM space as share memory for HDCP
key transmission.
BUG=chrome-os-partner:56883
TEST=WITH HDCP KEY SITUATION:
1.flash encrypt key to vpd area, and reboot chromebook.
$ vpd -O; vpd -s hdcp_key_v1_4=something...; dump_vpd_log
--force
2.write key to DP driver.
$ grep hdcp_key /var/cache/vpd/full-v2.txt | cut -s -d \" -f 4 |
tr -d "\n" > /sys/devices/platform/fec00000.dp/hdcp_key
Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/403972
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Sean Paul <seanpaul@google.com>
Change-Id: I0b97dcf938623685b6938d8a40285fac3b1d5045
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
This goes all the way back to the original KMS commit aeons ago
commit f453ba0460
Author: Dave Airlie <airlied@redhat.com>
Date: Fri Nov 7 14:05:41 2008 -0800
DRM: add mode setting support
But it seems to be completely unused. Only i915 and nouveau even
register these properties, and the corresponding DDX don't even look
at them. Also the sysfs files are read-only, so not useful to
configure anything.
I suspect that this was added with the goal to have read-only access
to all properties in sysfs, but we never followed through on that.
Also, that should be done in a more generic fashion.
Since it would be real work to fix up the locking (with atomic we're
now chasing pointers when reading properties) and it seems unused lets
just nuke this all. It's easier. Of course we'll keep the properties
themselves, those are still exposed through the KMS ioctls.
Change-Id: I35a54c6850127287de0c3f82cafb084900d76b97
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459331120-27864-5-git-send-email-daniel.vetter@ffwll.ch
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
(cherry picked from commit aa2e2996b1)
With atomic modesetting the hardware will be powered off when the
mode_set function is called. We should configure the hardware in the
enable function.
backport: merge output_mode change from Mark yao efd11cc8fa
("drm/rockchip: Correct vop out_mode configure")
Change-Id: Ic68911e7faa24b2e482448346585e3f7c19da1a6
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
(cherry picked from commit ef1844b7ed)
The clk_get_rate return 0 if something goes wrong, so it can never be
less then zero, the ret should be set a error code, otherwise the
cdn_dp_clk_enable will return 0 when it failed at clk_get_rate.
In addition, clk_get_rate() returns an "unsigned long", so use
"unsigned long" instead of "u32" is better.
Change-Id: I0da9a07b5b9fda5f1586e8179013739d47d7ea35
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1488940077-22297-2-git-send-email-zyw@rock-chips.com
(cherry picked from commit a68b5bb670)
Sometimes the Dock is disconnected, but cdn_dp_encoder_disable is not
triggered by DRM. For example, unplug the Dock in console mode, and
re-plug it again, the cdn_dp_event_work will try to get the sink count
of Dock, since the DP is still active. But the Dock has been powered
down, it need re-power on, and wait for a while until it is ready to
DPCD communication.
Change-Id: I59c17a7ce41d5697b33195894eaf4bb49ac85171
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
(cherry picked from commit 13e0e20694)
We're trying to lock mutex when cdn-dp shutdown, so we need to make
sure the mutex is inited in cdn-dp's probe.
Change-Id: Id414cb9441dbaa245ef9899c7972b080fba44d6b
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Chris Zhong <zyw@rock-chips.com>
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
(cherry picked from commit be0270e4d1)
Since msleep is based on jiffies the panel could take longer
than expected. So use msleep for values greater than 20 msec
otherwise usleep_range.
Change-Id: Ib03c6e381b44a31dd57aeaaa3a88a459578de313
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
The parameters of Synopsys PHY is programmed with the default values
for the corresponding hsfreqrange (test code 8'h44, HS RX Control of Lane 0)
Change-Id: I92c6bb0a9cad55e7b1695ca600f9c68804361dac
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
If edid can't be got when hdmi plug in, hdmi color depth mask and format
won't be updated. The color list in the setting are those of the previous
TV. This commit fix the error.
Change-Id: Iffe3164af1f1ad32002c26b5bbac14f2ff417c96
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
If edid can't be got when hdmi plug in, hdmi color depth mask and format
won't be updated. The color list in the setting are those of the previous
TV. This commit fix the error.
Change-Id: I5ed4be5efa2a69be0b58489f58a3af5de9912292
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
