linux-kernel - Re: [PATCH v2 5/5] drm/rockchip: default enable win2/3 area0 bit

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAAFQd5BCT_j1ZxMaaA-qaFct6+-VTJs4mEsZzGuFc=nL9jGNDA@mail.gmail.com>
Date:	Fri, 3 Jul 2015 18:24:11 +0900
From:	Tomasz Figa <tfiga@...omium.org>
To:	Mark yao <mark.yao@...k-chips.com>
Cc:	dri-devel <dri-devel@...ts.freedesktop.org>,
	David Airlie <airlied@...ux.ie>,
	Heiko Stuebner <heiko@...ech.de>,
	Daniel Kurtz <djkurtz@...omium.org>,
	Philipp Zabel <p.zabel@...gutronix.de>,
	Daniel Vetter <daniel@...ll.ch>,
	Rob Clark <robdclark@...il.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	sandy.huang@...k-chips.com, dkm@...k-chips.com, zwl@...k-chips.com,
	xw@...k-chips.com
Subject: Re: [PATCH v2 5/5] drm/rockchip: default enable win2/3 area0 bit

On Fri, Jul 3, 2015 at 5:19 PM, Mark yao <mark.yao@...k-chips.com> wrote:
> 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 <mark.yao@...k-chips.com> 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 <mark.yao@...k-chips.com>
>>> ---
>>> 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.

That's right. However, the vop_init_reg_table[] is only used at probe
time by vop_initial() and register settings listed there are not
applied any time later. If we call DPMS off, which will turn the VOP
off and in turn also the whole power domain off, won't the registers
be reset to default values (e.g. zeroed)?

Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/