Re: [PATCH v8 22/24] drm: rockchip: Add VOP2 driver
Hi Andy,
On Thu, Mar 17, 2022 at 03:23:12PM +0800, Andy Yan wrote:
>I found a obvious error in 0x604(OVERLAY_LAYER_SEL) register, the
>configuration value
>
>is 0x54763513.
>
>I am not sure if you know clearly about this register:
>
>Every four bits of this register select a Window(Cluster0,Cluster1,
>Esmart0, Esmart1, Smart0. Smart1)
>
>for layer0 to layer 5 from bottom to top.
>
>0: Cluster0
>
>1: Cluster1:
>
>2: Esmart0
>
>3: Smart0
>
>6: Esmart1
>
>7: Smart1
>
>And one window can only be selected by one layer at a time.
>
>So when I change this register to 0x54762513, the square draw by
>weston-simple-dmabuf-egl appeared on the top of the weston background on
>screen.
I can reproduce this here. It seems I have only tested overlays with two
active VPs. With only one active VP I see the same behaviour as you do.
The following patch fixes this, will include that in the next round.
Sascha
--8<---
>From d07036753bd1496fa8a49c31eff004e927ce412b Mon Sep 17 00:00:00 2001
From: Sascha Hauer
Date: Fri, 18 Mar 2022 09:47:53 +0100
Subject: [PATCH] fixup! drm: rockchip: Add VOP2 driver
---
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
index 81ff79eddb8a0..71bc8c11b8bcf 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
@@ -1941,7 +1941,7 @@ static void vop2_setup_layer_mixer(struct vop2_video_port
*vp)
}
/* configure unused layers to 0x5 (reserved) */
- for (; nlayer < 3; nlayer++) {
+ for (; nlayer < vp->nlayers; nlayer++) {
layer_sel &= ~RK3568_OVL_LAYER_SEL__LAYER(nlayer + ofs, 0x7);
layer_sel |= RK3568_OVL_LAYER_SEL__LAYER(nlayer + ofs, 5);
}
--
2.30.2
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH v8 22/24] drm: rockchip: Add VOP2 driver
Hi Sascha:
On 3/16/22 20:22, Andy Yan wrote:
Hi Sascha and Daniel:
On 3/16/22 15:40, Sascha Hauer wrote:
On Tue, Mar 15, 2022 at 02:46:35PM +0800, Andy Yan wrote:
Hi Sascha:
On 3/11/22 16:33, Sascha Hauer wrote:
From: Andy Yan
The VOP2 unit is found on Rockchip SoCs beginning with rk3566/rk3568.
It replaces the VOP unit found in the older Rockchip SoCs.
This driver has been derived from the downstream Rockchip Kernel and
heavily modified:
- All nonstandard DRM properties have been removed
- dropped struct vop2_plane_state and pass around less data between
functions
- Dropped all DRM_FORMAT_* not known on upstream
- rework register access to get rid of excessively used macros
- Drop all waiting for framesyncs
The driver is tested with HDMI and MIPI-DSI display on a RK3568-EVB
board. Overlay support is tested with the modetest utility. AFBC support
on the cluster windows is tested with weston-simple-dmabuf-egl on
weston using the (yet to be upstreamed) panfrost driver support.
Do we need some modification to test AFBC by weston-simple-dma-egl ?
By default weston-simple-dma-egl uses DRM_FORMAT_XRGB which in the
panfrost driver ends up as PIPE_FORMAT_B8G8R8_UNORM and
panfrost_afbc_format() returns PIPE_FORMAT_NONE for that. Change the
format to DRM_FORMAT_ABGR using weston-simple-dma-egl -f 0x34324241.
This ends up as PIPE_FORMAT_R8G8B8A8_UNORM in panfrost_afbc_format()
which is a supported format.
I also try weston-simple-dmabuf-egl -f 0x34324241 command,
but I got this output log from weston[0]:
Layer 5 (pos 0x5000):
View 0 (role xdg_toplevel, PID 375, surface ID 3, top-level window
'simple-dmabuf-egl' of org.freedesktop.weston.
simple-dmabuf-egl, 0xd08275e0):
position: (871, 174) -> (1127, 430)
[not opaque]
outputs: 0 (HDMI-A-1) (primary)
dmabuf buffer
format: 0x34324241 ABGR
modifier: ARM_BLOCK_SIZE=16x16,MODE=YTR|SPARSE (0x851)
Layer 6 (pos 0x2):
View 0 (role (null), PID 372, surface ID 18, background for output
HDMI-A-1, 0xd0863520):
position: (0, 0) -> (1920, 1080)
[fully opaque]
outputs: 0 (HDMI-A-1) (primary)
[buffer not available]
[repaint] preparing state for output HDMI-A-1 (0)
[repaint] trying planes-only build state
[view] evaluating view 0xd083b0f0 for output HDMI-A-1 (0)
[view] not assigning view 0xd083b0f0 to plane (no buffer available)
[view] failing state generation: placing view 0xd083b0f0 to
renderer not allowed
[repaint] could not build planes-only state, trying mixed
[state] using renderer FB ID 73 for mixed mode for output HDMI-A-1 (0)
[state] scanout will use for zpos 0
[view] evaluating view 0xd083b0f0 for output HDMI-A-1 (0)
[view] not assigning view 0xd083b0f0 to plane (no buffer available)
[view] view 0xd083b0f0 will be placed on the renderer
[view] evaluating view 0xd08275e0 for output HDMI-A-1 (0)
[plane] started with zpos 18446744073709551615
[view] view 0xd08275e0 will be placed on the renderer
[view] evaluating view 0xd0863520 for output HDMI-A-1 (0)
[view] not assigning view 0xd0863520 to plane (no buffer available)
[view] not assigning view 0xd0863520 to plane (occluded by
renderer views)
[view] view 0xd0863520 will be placed on the renderer
From the log we can find that Layer5 view 0(0xd08275e0) is the
afbc view rendered by Panfrost.
But it at last put on a render not a afbc window of vop "view] view
0xd083b0f0 will be placed on the renderer "
The output message from sys/kernel/debug/dri/state can also provide
that only non-AFBC window smart0-win0 is used.
It seems that it failed in weston drm_output_prepare_plane_view.
Maybe I need a deeper dig.
After a deeper dig, I found it failed from
drm_fb_get_from_dmabuf {
...
/* XXX: TODO:
*
* Currently the buffer is rejected if any dmabuf attribute
* flag is set. This keeps us from passing an inverted /
* interlaced / bottom-first buffer (or any other type that may
* be added in the future) through to an overlay. Ultimately,
* these types of buffers should be handled through buffer
* transforms and not as spot-checks requiring specific
* knowledge. */
if (dmabuf->attributes.flags) {
drm_debug(backend, "\t\t\t\t invlid flag 0x%x\n",
dmabuf->attributes.flags);
return NULL;
}
}
After some grep search, I found the flag is set at create_dmabuf_buffer
by weston-simple-dmabuf-egl itself.
So I run this test with -g: weston-simple-dmabuf-egl -f 0x34324241 -g
From the log I can see this view is go to a overlay plane, but it
doesn't appear on the screen.
Cat the dri state, I can see Cluster1-win0 this afbc window is enabled.
So I guess there is something wrong with the vop2 configuration.
I dump registers of OVERLAY and Cluster1-win0 and Smart0-win0(Primary plane)
I found a obvious error in 0x604(OVERLAY_LAYER_SEL) register, the
configuration value
is
Re: [PATCH v8 22/24] drm: rockchip: Add VOP2 driver
Hi Sascha and Daniel: On 3/16/22 15:40, Sascha Hauer wrote: On Tue, Mar 15, 2022 at 02:46:35PM +0800, Andy Yan wrote: Hi Sascha: On 3/11/22 16:33, Sascha Hauer wrote: From: Andy Yan The VOP2 unit is found on Rockchip SoCs beginning with rk3566/rk3568. It replaces the VOP unit found in the older Rockchip SoCs. This driver has been derived from the downstream Rockchip Kernel and heavily modified: - All nonstandard DRM properties have been removed - dropped struct vop2_plane_state and pass around less data between functions - Dropped all DRM_FORMAT_* not known on upstream - rework register access to get rid of excessively used macros - Drop all waiting for framesyncs The driver is tested with HDMI and MIPI-DSI display on a RK3568-EVB board. Overlay support is tested with the modetest utility. AFBC support on the cluster windows is tested with weston-simple-dmabuf-egl on weston using the (yet to be upstreamed) panfrost driver support. Do we need some modification to test AFBC by weston-simple-dma-egl ? By default weston-simple-dma-egl uses DRM_FORMAT_XRGB which in the panfrost driver ends up as PIPE_FORMAT_B8G8R8_UNORM and panfrost_afbc_format() returns PIPE_FORMAT_NONE for that. Change the format to DRM_FORMAT_ABGR using weston-simple-dma-egl -f 0x34324241. This ends up as PIPE_FORMAT_R8G8B8A8_UNORM in panfrost_afbc_format() which is a supported format. I also try weston-simple-dmabuf-egl -f 0x34324241 command, but I got this output log from weston[0]: Layer 5 (pos 0x5000): View 0 (role xdg_toplevel, PID 375, surface ID 3, top-level window 'simple-dmabuf-egl' of org.freedesktop.weston. simple-dmabuf-egl, 0xd08275e0): position: (871, 174) -> (1127, 430) [not opaque] outputs: 0 (HDMI-A-1) (primary) dmabuf buffer format: 0x34324241 ABGR modifier: ARM_BLOCK_SIZE=16x16,MODE=YTR|SPARSE (0x851) Layer 6 (pos 0x2): View 0 (role (null), PID 372, surface ID 18, background for output HDMI-A-1, 0xd0863520): position: (0, 0) -> (1920, 1080) [fully opaque] outputs: 0 (HDMI-A-1) (primary) [buffer not available] [repaint] preparing state for output HDMI-A-1 (0) [repaint] trying planes-only build state [view] evaluating view 0xd083b0f0 for output HDMI-A-1 (0) [view] not assigning view 0xd083b0f0 to plane (no buffer available) [view] failing state generation: placing view 0xd083b0f0 to renderer not allowed [repaint] could not build planes-only state, trying mixed [state] using renderer FB ID 73 for mixed mode for output HDMI-A-1 (0) [state] scanout will use for zpos 0 [view] evaluating view 0xd083b0f0 for output HDMI-A-1 (0) [view] not assigning view 0xd083b0f0 to plane (no buffer available) [view] view 0xd083b0f0 will be placed on the renderer [view] evaluating view 0xd08275e0 for output HDMI-A-1 (0) [plane] started with zpos 18446744073709551615 [view] view 0xd08275e0 will be placed on the renderer [view] evaluating view 0xd0863520 for output HDMI-A-1 (0) [view] not assigning view 0xd0863520 to plane (no buffer available) [view] not assigning view 0xd0863520 to plane (occluded by renderer views) [view] view 0xd0863520 will be placed on the renderer From the log we can find that Layer5 view 0(0xd08275e0) is the afbc view rendered by Panfrost. But it at last put on a render not a afbc window of vop "view] view 0xd083b0f0 will be placed on the renderer " The output message from sys/kernel/debug/dri/state can also provide that only non-AFBC window smart0-win0 is used. It seems that it failed in weston drm_output_prepare_plane_view. Maybe I need a deeper dig. [0] https://pastebin.com/8CfiP7u1 I have a buildroot system with weston-10.0.9 and mesa 21.3.5. After launch weston, I run weston-simple-dmabuf-egl, but from the output of sys/kernel/debug/dri/0/state, the weston is still use Smart0-win0, which is a non-AFBC window. Do i need to modify the vop2 driver to set one Cluster window as primary plane? I never used a Cluster window as primary plane. Sascha
Re: [PATCH v8 22/24] drm: rockchip: Add VOP2 driver
On Tue, Mar 15, 2022 at 02:46:35PM +0800, Andy Yan wrote: > Hi Sascha: > > On 3/11/22 16:33, Sascha Hauer wrote: > > From: Andy Yan > > > > The VOP2 unit is found on Rockchip SoCs beginning with rk3566/rk3568. > > It replaces the VOP unit found in the older Rockchip SoCs. > > > > This driver has been derived from the downstream Rockchip Kernel and > > heavily modified: > > > > - All nonstandard DRM properties have been removed > > - dropped struct vop2_plane_state and pass around less data between > >functions > > - Dropped all DRM_FORMAT_* not known on upstream > > - rework register access to get rid of excessively used macros > > - Drop all waiting for framesyncs > > > > The driver is tested with HDMI and MIPI-DSI display on a RK3568-EVB > > board. Overlay support is tested with the modetest utility. AFBC support > > on the cluster windows is tested with weston-simple-dmabuf-egl on > > weston using the (yet to be upstreamed) panfrost driver support. > > Do we need some modification to test AFBC by weston-simple-dma-egl ? By default weston-simple-dma-egl uses DRM_FORMAT_XRGB which in the panfrost driver ends up as PIPE_FORMAT_B8G8R8_UNORM and panfrost_afbc_format() returns PIPE_FORMAT_NONE for that. Change the format to DRM_FORMAT_ABGR using weston-simple-dma-egl -f 0x34324241. This ends up as PIPE_FORMAT_R8G8B8A8_UNORM in panfrost_afbc_format() which is a supported format. > > I have a buildroot system with weston-10.0.9 and mesa 21.3.5. > > After launch weston, I run weston-simple-dmabuf-egl, but from the output > > of sys/kernel/debug/dri/0/state, the weston is still use Smart0-win0, which > is > > a non-AFBC window. > > Do i need to modify the vop2 driver to set one Cluster window as primary > plane? I never used a Cluster window as primary plane. Sascha -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH v8 22/24] drm: rockchip: Add VOP2 driver
Hi Daniel: On 3/15/22 20:43, Daniel Stone wrote: Hi Andy, On Tue, 15 Mar 2022 at 06:46, Andy Yan wrote: On 3/11/22 16:33, Sascha Hauer wrote: The driver is tested with HDMI and MIPI-DSI display on a RK3568-EVB board. Overlay support is tested with the modetest utility. AFBC support on the cluster windows is tested with weston-simple-dmabuf-egl on weston using the (yet to be upstreamed) panfrost driver support. Do we need some modification to test AFBC by weston-simple-dma-egl ? I have a buildroot system with weston-10.0.9 and mesa 21.3.5. After launch weston, I run weston-simple-dmabuf-egl, but from the output of sys/kernel/debug/dri/0/state, the weston is still use Smart0-win0, which is a non-AFBC window. Do i need to modify the vop2 driver to set one Cluster window as primary plane? Are you using the open-source Panfrost driver, or the proprietary Arm DDK? The DDK was previously using some non-standard modifier tokens which have since been corrected upstream. I use mesa 21.3.5 with open-source Panfrost driver enabled. When I modify Sascha's vop2 driver, set a Cluster windows as primary plane, Then launch weston, vop2 report POST_BUF_EMPTY irq err. From the log I can see many "panfrost fde6.gpu: js fault, js=0, status=DATA_INVALID_FAULT" [0] I check the register configuration of Cluster window, there is no obvious error. I event run a ovltest[1] written by myself feed a AFBC RGB data to Cluster0. it can display ok. It seems that the basic afbc configuration of vop2 is right, but something is wrong with Panfrost? [0]https://pastebin.com/ydZkSz1f [1]https://gitee.com/andyshrk/drm/tree/master/tests/ovltest You can see from running `weston-debug drm-backend` (if you start Weston with `--debug`) the output as it tries to put client surfaces on to overlay planes, and why it can or cannot. For Weston's own composited output (used when it cannot place client surfaces on to planes), it will just use whatever the KMS driver declares as the primary plane. Weston does not have any logic to say 'oh, this plane is AFBC and AFBC is better, so I will use this as my primary plane': we just follow what the kernel tells us. Cheers, Daniel
Re: [PATCH v8 22/24] drm: rockchip: Add VOP2 driver
Hi Andy, On Tue, 15 Mar 2022 at 06:46, Andy Yan wrote: > On 3/11/22 16:33, Sascha Hauer wrote: > > The driver is tested with HDMI and MIPI-DSI display on a RK3568-EVB > > board. Overlay support is tested with the modetest utility. AFBC support > > on the cluster windows is tested with weston-simple-dmabuf-egl on > > weston using the (yet to be upstreamed) panfrost driver support. > > Do we need some modification to test AFBC by weston-simple-dma-egl ? > > I have a buildroot system with weston-10.0.9 and mesa 21.3.5. > > After launch weston, I run weston-simple-dmabuf-egl, but from the output > > of sys/kernel/debug/dri/0/state, the weston is still use Smart0-win0, > which is > > a non-AFBC window. > > Do i need to modify the vop2 driver to set one Cluster window as primary > plane? Are you using the open-source Panfrost driver, or the proprietary Arm DDK? The DDK was previously using some non-standard modifier tokens which have since been corrected upstream. You can see from running `weston-debug drm-backend` (if you start Weston with `--debug`) the output as it tries to put client surfaces on to overlay planes, and why it can or cannot. For Weston's own composited output (used when it cannot place client surfaces on to planes), it will just use whatever the KMS driver declares as the primary plane. Weston does not have any logic to say 'oh, this plane is AFBC and AFBC is better, so I will use this as my primary plane': we just follow what the kernel tells us. Cheers, Daniel
Re: [PATCH v8 22/24] drm: rockchip: Add VOP2 driver
Hi Sascha: On 3/11/22 16:33, Sascha Hauer wrote: From: Andy Yan The VOP2 unit is found on Rockchip SoCs beginning with rk3566/rk3568. It replaces the VOP unit found in the older Rockchip SoCs. This driver has been derived from the downstream Rockchip Kernel and heavily modified: - All nonstandard DRM properties have been removed - dropped struct vop2_plane_state and pass around less data between functions - Dropped all DRM_FORMAT_* not known on upstream - rework register access to get rid of excessively used macros - Drop all waiting for framesyncs The driver is tested with HDMI and MIPI-DSI display on a RK3568-EVB board. Overlay support is tested with the modetest utility. AFBC support on the cluster windows is tested with weston-simple-dmabuf-egl on weston using the (yet to be upstreamed) panfrost driver support. Do we need some modification to test AFBC by weston-simple-dma-egl ? I have a buildroot system with weston-10.0.9 and mesa 21.3.5. After launch weston, I run weston-simple-dmabuf-egl, but from the output of sys/kernel/debug/dri/0/state, the weston is still use Smart0-win0, which is a non-AFBC window. Do i need to modify the vop2 driver to set one Cluster window as primary plane?
Re:[PATCH v8 22/24] drm: rockchip: Add VOP2 driver
Hi Sascha Hauer From: Sascha Hauer Date: 2022-03-11 16:33:21 To: dri-devel@lists.freedesktop.org Cc: linux-arm-ker...@lists.infradead.org,linux-rockc...@lists.infradead.org,devicet...@vger.kernel.org,ker...@pengutronix.de,Andy Yan ,Benjamin Gaignard ,Michael Riesch ,Sandy Huang ,"Heiko Stübner" ,Peter Geis ,Sascha Hauer Subject: [PATCH v8 22/24] drm: rockchip: Add VOP2 driver>From: Andy Yan > >The VOP2 unit is found on Rockchip SoCs beginning with rk3566/rk3568. >It replaces the VOP unit found in the older Rockchip SoCs. > >This driver has been derived from the downstream Rockchip Kernel and >heavily modified: > >- All nonstandard DRM properties have been removed >- dropped struct vop2_plane_state and pass around less data between > functions >- Dropped all DRM_FORMAT_* not known on upstream >- rework register access to get rid of excessively used macros >- Drop all waiting for framesyncs > >The driver is tested with HDMI and MIPI-DSI display on a RK3568-EVB >board. Overlay support is tested with the modetest utility. AFBC support >on the cluster windows is tested with weston-simple-dmabuf-egl on >weston using the (yet to be upstreamed) panfrost driver support. > >Signed-off-by: Andy Yan >Signed-off-by: Sascha Hauer >--- > >Notes: >Changes since v6: >- Drop device tree parsing during runtime >- Fix typo in Kconfig help text > >Changes since v5: >- consistently use u8/u16/u32 rather than uint8_t/uint16_t/uint32_t >- Use spin_lock rather than spin_lock_irqsave >- replace printk with drm_dbg >- break some overlong lines > >Changes since v4: >- Avoid stack frame overflow by not allocating big array on the stack > >Changes since v3: >- Sort includes >- fix typos >- Drop spinlock >- Use regmap_set_bits()/regmap_clear_bits() >- simplify vop2_scale_factor() >- simplify vop2_afbc_transform_offset() > >Changes since v4: >- Sort nodes alphabetically > >Changes since v3: >- Fix HDMI connector type > >Changes since v4: >- Add Robs Ack > >Changes since v3: >- Bring back gamma_lut regs >- Drop redundant _vop suffix from clock names > >Changes since v5: >- Drop unnecessary #size-cells/#address-cells from nodes with only single > endpoint > >Changes since v5: >- consistently use u8/u16/u32 rather than uint8_t/uint16_t/uint32_t >- Use spin_lock rather than spin_lock_irqsave >- replace printk with drm_dbg >- break some overlong lines > >Changes since v4: >- Avoid stack frame overflow by not allocating big array on the stack > >Changes since v3: >- Sort includes >- fix typos >- Drop spinlock >- Use regmap_set_bits()/regmap_clear_bits() >- simplify vop2_scale_factor() >- simplify vop2_afbc_transform_offset() > >Changes since v4: >- Sort nodes alphabetically > >Changes since v3: >- Fix HDMI connector type > > drivers/gpu/drm/rockchip/Kconfig |6 + > drivers/gpu/drm/rockchip/Makefile|1 + > drivers/gpu/drm/rockchip/rockchip_drm_drv.c |1 + > drivers/gpu/drm/rockchip/rockchip_drm_drv.h |6 +- > drivers/gpu/drm/rockchip/rockchip_drm_fb.c |2 + > drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 15 + > drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 2686 ++ > drivers/gpu/drm/rockchip/rockchip_drm_vop2.h | 477 > drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 281 ++ > 9 files changed, 3474 insertions(+), 1 deletion(-) > create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop2.c > create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop2.h > create mode 100644 drivers/gpu/drm/rockchip/rockchip_vop2_reg.c > >diff --git a/drivers/gpu/drm/rockchip/Kconfig >b/drivers/gpu/drm/rockchip/Kconfig >index b9b156308460a..f033971103610 100644 >--- a/drivers/gpu/drm/rockchip/Kconfig >+++ b/drivers/gpu/drm/rockchip/Kconfig >@@ -28,6 +28,12 @@ config ROCKCHIP_VOP > This selects support for the VOP driver. You should enable it > on all older SoCs up to RK3399. > >+config ROCKCHIP_VOP2 >+ bool "Rockchip VOP2 driver" >+ help >+This selects support for the VOP2 driver. You should enable it >+on all newer SoCs beginning from RK3568. >+ rockchip newer SoCs maybe still use the old vop driver, and we are designing the next VOP, i am not sure if we will use the vop2 driver. so we can't say: "You should enable it on all newer SoCs beginning from RK3568." thanks, sandy. > config ROCKCHIP_ANALOGIX_DP > bool "Rockchip specific extensions for Analogix DP driver" > depends on ROCKCHIP_VOP >diff --git a/drivers/gpu/drm/rockchip/Makefile >b/drivers/gpu/drm/rockchip/Makefile >index dfc5512fdb9f1..3ff7b21c04149 100644 >--- a/drivers/gpu/drm/rockchip/Makefile >+++ b/drivers/gpu/drm/rockchip/Makefile >@@ -6,6 +6,7 @@ > rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \ >
