Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754850AbbGCITz (ORCPT ); Fri, 3 Jul 2015 04:19:55 -0400 Received: from regular1.263xmail.com ([211.150.99.139]:53291 "EHLO regular1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754843AbbGCITe (ORCPT ); Fri, 3 Jul 2015 04:19:34 -0400 X-263anti-spam: KSV:0; X-MAIL-GRAY: 0 X-MAIL-DELIVERY: 1 X-KSVirus-check: 0 X-ABS-CHECKED: 4 X-ADDR-CHECKED: 0 X-RL-SENDER: mark.yao@rock-chips.com X-FST-TO: tfiga@chromium.org X-SENDER-IP: 58.22.7.114 X-LOGIN-NAME: mark.yao@rock-chips.com X-UNIQUE-TAG: <7ffcfd8e218520792fd3572e1ab1d82b> X-ATTACHMENT-NUM: 0 X-DNS-TYPE: 0 Message-ID: <5596457F.5090601@rock-chips.com> Date: Fri, 03 Jul 2015 16:19:11 +0800 From: Mark yao User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Tomasz Figa CC: dri-devel , David Airlie , Heiko Stuebner , Daniel Kurtz , Philipp Zabel , Daniel Vetter , Rob Clark , "linux-arm-kernel@lists.infradead.org" , "open list:ARM/Rockchip SoC..." , "linux-kernel@vger.kernel.org" , sandy.huang@rock-chips.com, dkm@rock-chips.com, zwl@rock-chips.com, xw@rock-chips.com Subject: Re: [PATCH v2 5/5] drm/rockchip: default enable win2/3 area0 bit References: <1435313249-4549-1-git-send-email-mark.yao@rock-chips.com> <1435313432-4923-1-git-send-email-mark.yao@rock-chips.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2779 Lines: 79 On 2015年07月03日 16:02, Tomasz Figa wrote: > Hi Mark, > > Please see my comments inline. > > On Fri, Jun 26, 2015 at 7:10 PM, Mark Yao wrote: >> Win2/3 support 4 area display, but now havn't found a suitable >> way to use it, and it enable by win gate and area gate, >> so default enable area0 gate, so that its behaviour just like a >> win. > So I assume this means that currently, without those bits set, win2 > and win3 do not work? This would make this patch a fix maybe even with > a potential backportability. Yes, without this patch, all win2/3 area gate default disabled. vop_update_plane_event call win enable only enable the win gate. > >> Signed-off-by: Mark Yao >> --- >> Changes in v2: None >> >> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 6 ++++++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c >> index 40107bb..e001d26 100644 >> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c >> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c >> @@ -337,6 +337,12 @@ static const struct vop_reg_data vop_init_reg_table[] = { >> {DSP_CTRL0, 0x00000000}, >> {WIN0_CTRL0, 0x00000080}, >> {WIN1_CTRL0, 0x00000080}, >> + /* >> + * Todo: win2/3 support area func, but now havn't found a suitable >> + * way to use it, so default enable area0 as a win display. > TODO: Win2/3 support multiple area function, but we haven't found > a suitable way to use it yet, so let's just use them as other windows > with only area 0 enabled. > >> + */ >> + {WIN2_CTRL0, 0x00000010}, >> + {WIN3_CTRL0, 0x00000010}, > Anyway, is it enough to program those registers one time in > vop_initial()? Won't they get cleared when VOP is power cycled, e.g. > in case of DPMS off and on? Maybe instead this could be done in > vop_update_plane_event() for windows that need it? There are two gate for Win2/3, at VOP_WIN3_CTRL0: bit[0], "win3_en" this gating all the area. bit[4], win3_mst0_en bit[5], win3_mst1_en bit[6], win3_mst2_en bit[7], win3_mst3_en those gate each area. This patch default enable win3_mst0_en, so control bit[0]"win3_en" that cat power on/off this window. vop_update_plane_event()/ vop_disable_plane() only can control bit[0]"win3_en". So this patch is enough to enable window2/3 area 0. > Best regards, > Tomasz -- Ｍark -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/