linux-kernel - Re: [RFC PATCH v1 0/2]

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] [day] [month] [year] [list]

Message-ID: <20160602141910.GL7231@phenom.ffwll.local>
Date:	Thu, 2 Jun 2016 16:19:11 +0200
From:	Daniel Vetter <daniel@...ll.ch>
To:	Yakir Yang <ykk@...k-chips.com>
Cc:	daniel.vetter@...el.com,
	Krzysztof Kozlowski <k.kozlowski@...sung.com>,
	linux-samsung-soc@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-rockchip@...ts.infradead.org, Mark Yao <yzq@...k-chips.com>,
	Jingoo Han <jingoohan1@...il.com>, emil.l.velikov@...il.com,
	dianders@...omium.org, dri-devel@...ts.freedesktop.org,
	tfiga@...omium.org, Thierry Reding <treding@...dia.com>,
	Dan Carpenter <dan.carpenter@...cle.com>
Subject: Re: [RFC PATCH v1 0/2]

On Wed, Jun 01, 2016 at 10:54:09AM +0800, Yakir Yang wrote:
> Hi Daniel,
> 
> On 05/31/2016 10:38 PM, Daniel Vetter wrote:
> > On Tue, May 31, 2016 at 09:37:36PM +0800, Yakir Yang wrote:
> > > The full name of PSR is Panel Self Refresh, panel device could refresh
> > > itself with the hardware framebuffer in panel, this would make a lots
> > > of sense to save the power consumption.
> > > 
> > > For example, when desktop haven't change the context for a long time,
> > > then we could refresh the data to the hardware framebuffer of panel,
> > > and then let panel enter into PSR mode. After that system could poweroff
> > > the LCDC controller and eDP controller, just let panel refresh the screen
> > > by itself.
> > > 
> > > It's hard to decide when panel should enter into PSR or exit from PSR, in
> > > this time I chose to let the drm_vblank enable/disable event driver the PSR.
> > > 
> > > This thread is based on Mark's RK3399 VOP thread[0] and my RK3399 eDP
> > > thread[1].
> > > 
> > > [0]: https://patchwork.kernel.org/patch/8886041/
> > > [1]: https://patchwork.kernel.org/patch/9132713/
> > Looks like you didn't wire up the drm_framebuffer->funcs->dirty callback
> > for manual upload of simple clients like bootsplash or fbdev. I think
> > that's needed. At least it's needed for every other manual upload dsi and
> > edp psr implementation.
> > -Daniel
> That's great, thanks for your remind. Seems like userspace which does
> frontbuffer rendering must call this ioctl to flush out the changes on
> manual-update display outputs. It's helpful to hook this callback to
> notify eDP refresh the eDP RFB(remote frame buffer).
> 
> But I think this is hard to used on Rockchip eDP controller, Rockchip eDP
> driver just used two modes, Sink Device PSR_S0 (PSR inactive), and Sink
> Device PSR_S2 (PSR active, display from RFB).
> 
> I think the "dirty" callback is only used when Sink device enter into PSR_S3
> mode (PSR active, capture and display), need to update the remote frame
> buffer. But on Rockchip platform the panel would be very easy to lose frame
> in this PSR mode. I'm confused in this case, so I didn't enable that.
> 
> If we didn't enable the PSR_S3 mode, then we don't need to update the panel
> remote frame buffer, so this "->dirty" callback would be unused in this
> case.

Sorry missed your reply here somehow. Every time you don't scan out the
drm_framebuffer directly, but from any kind of intermediate buffer, you
_must_ implement the dirty callback. Usually the simplest way is to kick
the device out of self-refresh and arm the time to re-enter self-refresh.

I'm not entirely clear where your RFB is, so no idea whether that is
scanning out from the drm_framebuffer data directly, or whether that's
some on-chip or in-sink framebuffer cache.

We have a ridiculously nasty testuite in i-g-t for all these cases (we use
it to validate our framebuffer compression code, psr code and soon also
dsi manual upload). Unfortunately it's not yet ported over to be a generic
testcase. But at least for PSR that would be easy, since every PSR panel
has eDP sink crc support. And the testcase does require some kind of
display CRC support to validate actual screen contents, as opposed to
what's in memory in the drm_framebuffer.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch