Thers is a phy config clock in RK3399, it must be enable before phy
init, and be disable after phy init.
Change-Id: Idb2d4c85f5284065c3f1d540d9e2fddf5565040d
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
fix warning:
warning: format '%x' expects argument of type 'unsigned int',
but argument 2 has type 'size_t'
Change-Id: Ifab0d16f0229aa3d5fc244678298fa2138bd4aa1
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
The vopb/vopl switch register of rk3399 mipi is different from rk3288,
the default setting for mipi dsi mode is different too, so add a
of_device_id structure to distinguish them, and make sure set the
correct mode before mipi phy init.
Change-Id: I54542752dddd1b28fc0500c0a763f14c29fe98f0
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
This patch is learn from Marek Szyprowski's patch:
(drm/exynos: rewrite IOMMU support code)
The patch replaces usage of ARM-specific IOMMU/DMA-mapping related calls
with new generic code for managing DMA-IOMMU integration layer. It also
removes all the hacks, which were needed to configure common DMA/IO address
space on the virtual rockchip-drm device.
Change-Id: I5d2b90002bf135a72ce30cc8503a7d06769835f3
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
There are two VOP in rk3399 chip, respectively VOP_BIG and VOP_LIT.
most registers layout of this two vop is same, their framework arm both
VOP_FULL, the Major differences of this two is that:
VOP_BIG max output resolution is 4096x2160.
VOP_LIT max output resolution is 2560x1600
VOP_BIG support four windows.
VOP_LIT only support two windows.
RK3399 vop register layout is similar with rk3288, so some feature can reuse
with rk3288.
Change-Id: I76f94c93b0e63e4fbba51755e92c604211613e8b
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
We need to take care of the vop status when use rockchip_drm_crtc_mode_config,
if vop is disabled, the function would failed, that is terrible.
Save connector type and output mode on drm_display_mode->private_flags on
connector mode_fixup, then we can configure the type and mode safely
on crtc mode_set.
Change-Id: I129cf8a2f100fc19fe96f1d8985e905bea477e28
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
The Rockchip dw_hdmi driver just called platform_set_drvdata() to get
your hopes up that maybe, somehow, you'd be able to retrieve the 'struct
rockchip_hdmi' from a pointer to the 'struct device'. You can't. When
we call dw_hdmi_bind() the main driver calls dev_set_drvdata(), which
clobbers our setting.
Let's just remove the platform_set_drvdata() to avoid dashing people's
hopes.
(am from https://patchwork.kernel.org/patch/8523401/)
Change-Id: I28c4dcff37f6800b841e0492eb2613dcff7d1c81
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
This fixes a few problems in the vop crtc cleanup (handling error
paths and cleanup upon exit):
* The vop_create_crtc() error path had an unsafe version of the
iterator used for iterating over all planes (though it was
destroying planes in the iterator so should have used the safe
version)
* vop_destroy_crtc() - wasn't calling vop_plane_destroy(), which made
slub_debug unhappy, at least if we ended up running this due to a
deferred probe.
* In vop_create_crtc() if we were missing the "port" device tree node
we would fail but not return an error (found by code inspection).
Fix these problems.
(am from https://patchwork.kernel.org/patch/8523361/)
Change-Id: I3c00faca6e2fc10edc5b4576012ac28b6809a2f3
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
The drm_encoder_cleanup() was missing both from the error path of
dw_hdmi_rockchip_bind(). This caused a crash when slub_debug was
enabled and we ended up deferring probe of HDMI at boot.
This call isn't needed from unbind() because if dw_hdmi_bind() returns
no error then it takes over the job of freeing the encoder (in
dw_hdmi_unbind).
(am from https://patchwork.kernel.org/patch/8523331/)
Change-Id: Ibf5c39a5db304177a9f16d8dc691221512002348
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
When closing the DRM device while a vblank is pending, we access
file_priv after it has been free'd, which gives:
Unable to handle kernel NULL pointer dereference at virtual address 00000000
...
PC is at __list_add+0x5c/0xe8
LR is at send_vblank_event+0x54/0x1f0
...
[<c02952e8>] (__list_add) from [<c031a7b4>] (send_vblank_event+0x54/0x1f0)
[<c031a760>] (send_vblank_event) from [<c031a9c0>] (drm_send_vblank_event+0x70/0x78)
[<c031a950>] (drm_send_vblank_event) from [<c031a9f8>] (drm_crtc_send_vblank_event+0x30/0x34)
[<c031a9c8>] (drm_crtc_send_vblank_event) from [<c0339ad8>] (vop_isr+0x224/0x28c)
[<c03398b4>] (vop_isr) from [<c0081780>] (handle_irq_event_percpu+0x12c/0x3e4)
This can be triggered somewhat reliably with:
modetest -M rockchip -v -s ...
Add a preclose hook to the driver so that we can discard any pending
vblank events when the device is closed.
(am from https://patchwork.kernel.org/patch/8568111)
Change-Id: Icce075cf22f3a9d7b2157c29a47b370160b0c8d8
Signed-off-by: John Keeping <john@metanate.com>
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
RK3399 and RK3288 shared the same eDP IP controller, so this time we
just need to append the RK3399 compatible name to analogix_dp documentation
and driver code.
Change-Id: I3fee6893c56698ee2948b9df2f3ffb7729fe75ef
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
There're an register define error in ANALOGIX_DP_PLL_REG_1 which introduced
by commit 45970584ea (FROMLIST: drm: bridge:
analogix/dp: add some rk3288 special registers setting).
The PHY PLL input clock source is selected by ANALOGIX_DP_PLL_REG_1
BIT 0, not BIT 1.
Change-Id: I8cb806d23144697225f626aaa2af19e6379dfe51
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
* linux-linaro-lsk-v4.4-android: (477 commits)
arm64: vdso: Mark vDSO code as read-only
ARM/vdso: Mark the vDSO code read-only after init
x86/vdso: Mark the vDSO code read-only after init
lkdtm: Verify that '__ro_after_init' works correctly
arch: Introduce post-init read-only memory
x86/mm: Always enable CONFIG_DEBUG_RODATA and remove the Kconfig option
mm/init: Add 'rodata=off' boot cmdline parameter to disable read-only kernel mappings
asm-generic: Consolidate mark_rodata_ro()
Linux 4.4.6
ld-version: Fix awk regex compile failure
target: Drop incorrect ABORT_TASK put for completed commands
block: don't optimize for non-cloned bio in bio_get_last_bvec()
MIPS: smp.c: Fix uninitialised temp_foreign_map
MIPS: Fix build error when SMP is used without GIC
ovl: fix getcwd() failure after unsuccessful rmdir
ovl: copy new uid/gid into overlayfs runtime inode
userfaultfd: don't block on the last VM updates at exit time
powerpc/powernv: Fix OPAL_CONSOLE_FLUSH prototype and usages
powerpc/powernv: Add a kmsg_dumper that flushes console output on panic
powerpc: Fix dedotify for binutils >= 2.26
...
It may caused a dead lock if we flush the hpd work in bridge disable time.
The normal flow would like:
IN --> DRM IOCTL
1. Acquire crtc_ww_class_mutex (DRM IOCTL)
IN --> analogix_dp_bridge
2. Acquire hpd work lock (Flush hpd work)
3. HPD work already in idle, no need to run the work function.
OUT <-- analogix_dp_bridge
OUT <-- DRM IOCTL
The dead lock flow would like:
IN --> DRM IOCTL
1. Acquire crtc_ww_class_mutex (DRM IOCTL)
IN --> analogix_dp_bridge
2. Acquire hpd work lock (Flush hpd work)
IN --> analogix_dp_hotplug
IN --> drm_helper_hpd_irq_event
3. Acquire mode_config lock (This lock already have been acquired in previous step 1)
** Dead Lock Now **
It's wrong to flush the hpd work in bridge->disable time, I guess the
original code just want to ensure the delay work must be finish before
encoder disabled.
The flush work in bridge disable time is try to ensure the HPD event
won't be missed before display card disabled, actually we can take a
fast respond way(interrupt thread) to update DRM HPD event to fix the
delay update and possible dead lock.
(am from https://patchwork.kernel.org/patch/8313001/)
Change-Id: Id7b357de0f497ff8c9f259fe31dc28be34f17083
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Display Port monitor could support kinds of mode which indicate
in monitor edid, not just one single display resolution which
defined in panel or devivetree property display timing.
Note: Gustavo Padovan try to remove the controller and phy
power on function in bind time at bellow commit:
drm/exynos: do not start enabling DP at bind() phase
But for now driver need to read edid message in .get_modes()
function, so controller must be inited in bind time, so we
need to add controller init back.
(am from https://patchwork.kernel.org/patch/8312921/)
Change-Id: I32abee21665a7e1470f2898b7fbc925108f9d768
Tested-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
This change just make a little clean to make code more like
drm core expect, move hdp detect code from bridge->enable(),
and place them into connector->detect().
Note: Gustavo Padovan try to remove the controller and phy
power on function in bind time at bellow commit:
drm/exynos: do not start enabling DP at bind() phase
But for now the connector status don't hardcode to connected,
need to operate dp phy in .detect function, so we need to revert
parts if Gustavo Padovan's changes, add phy poweron
function in bind time.
(am from https://patchwork.kernel.org/patch/8312901/)
Change-Id: I0ed1be541210f85883477f1b2a88bd8d57e390d6
Tested-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Some edp screen do not have hpd signal, so we can't just return
failed when hpd plug in detect failed.
This is an hardware property, so we need add a devicetree property
"analogix,need-force-hpd" to indicate this sutiation.
(am from https://patchwork.kernel.org/patch/8313081/)
Change-Id: If99d29936aafd996c98568d6e184aee6d9c8bc47
Acked-by: Rob Herring <robh@kernel.org>
Tested-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
There are some IP limit on rk3288 that only support 4 physical lanes
of 2.7/1.6 Gbps/lane, so seprate them out by device_type flag.
(am from https://patchwork.kernel.org/patch/8312881/)
Change-Id: Id1432af874eb0a6dec819d7b7e735c1040f4bf5c
Tested-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
RK3288 need some special registers setting, we can separate
them out by the dev_type of plat_data.
(am from https://patchwork.kernel.org/patch/8312861/)
Change-Id: I422216f58a18f2c2fee187b4f19de7b9d0fcd05a
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Rockchip have three clocks for dp controller, we leave pclk_edp
to analogix_dp driver control, and keep the sclk_edp_24m and
sclk_edp in platform driver.
(am from https://patchwork.kernel.org/patch/8615371/)
Change-Id: Ibe22447ab881b7421e999479cbdfd529d183f6b4
Tested-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Both hsync/vsync polarity and interlace mode can be parsed from
drm display mode, and dynamic_range and ycbcr_coeff can be judge
by the video code.
But presumably Exynos still relies on the DT properties, so take
good use of mode_fixup() in to achieve the compatibility hacks.
(am from https://patchwork.kernel.org/patch/8312791/)
Change-Id: Ia7f37daf40fa2d0516d5c44737ad36b5822c6015
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Tested-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
link_rate and lane_count already configured in analogix_dp_set_link_train(),
so we don't need to config those repeatly after training finished, just
remove them out.
Beside Display Port 1.2 already support 5.4Gbps link rate, the maximum sets
would change from {1.62Gbps, 2.7Gbps} to {1.62Gbps, 2.7Gbps, 5.4Gbps}.
(am from https://patchwork.kernel.org/patch/8312771/)
Change-Id: I8cbf7146d70143bb5d30b3fa971e19f034c30e62
Tested-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
