From: Yakir Yang <ykk@rock-chips.com> To: daniel.vetter@intel.com Cc: Mark Yao <yzq@rock-chips.com>, Inki Dae <inki.dae@samsung.com>, Heiko Stuebner <heiko@sntech.de>, tfiga@chromium.org, Jingoo Han <jingoohan1@gmail.com>, David Airlie <airlied@linux.ie>, Thierry Reding <treding@nvidia.com>, dianders@chromium.org, Krzysztof Kozlowski <k.kozlowski@samsung.com>, emil.l.velikov@gmail.com, Dan Carpenter <dan.carpenter@oracle.com>, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-samsung-soc@vger.kernel.org, linux-rockchip@lists.infradead.org Subject: Re: [RFC PATCH v1 0/2] Date: Wed, 1 Jun 2016 10:54:09 +0800 [thread overview] Message-ID: <574E4E51.1030308@rock-chips.com> (raw) In-Reply-To: <20160531143831.GK7231@phenom.ffwll.local> 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. Thanks, - Yakir >> - Yakir >> Thanks, >> >> >> Yakir Yang (2): >> drm/rockchip: add a notify event about vblank enable/disable >> drm/rockchip: analogix: add eDP PSR function >> >> drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 69 ++++++++++++++ >> drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 5 + >> drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 54 +++++++++++ >> drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h | 28 ++++++ >> drivers/gpu/drm/rockchip/Makefile | 2 +- >> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 65 +++++++++++++ >> drivers/gpu/drm/rockchip/rockchip_drm_notify.c | 105 +++++++++++++++++++++ >> drivers/gpu/drm/rockchip/rockchip_drm_notify.h | 33 +++++++ >> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 96 +++++++++++++++++++ >> drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 3 + >> drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 2 + >> include/drm/bridge/analogix_dp.h | 3 + >> 12 files changed, 464 insertions(+), 1 deletion(-) >> create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_notify.c >> create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_notify.h >> >> -- >> 1.9.1 >> >>
WARNING: multiple messages have this Message-ID (diff)
From: Yakir Yang <ykk@rock-chips.com> To: daniel.vetter@intel.com Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>, linux-samsung-soc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org, Mark Yao <yzq@rock-chips.com>, Jingoo Han <jingoohan1@gmail.com>, emil.l.velikov@gmail.com, dianders@chromium.org, dri-devel@lists.freedesktop.org, tfiga@chromium.org, Thierry Reding <treding@nvidia.com>, Dan Carpenter <dan.carpenter@oracle.com> Subject: Re: [RFC PATCH v1 0/2] Date: Wed, 1 Jun 2016 10:54:09 +0800 [thread overview] Message-ID: <574E4E51.1030308@rock-chips.com> (raw) In-Reply-To: <20160531143831.GK7231@phenom.ffwll.local> 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. Thanks, - Yakir >> - Yakir >> Thanks, >> >> >> Yakir Yang (2): >> drm/rockchip: add a notify event about vblank enable/disable >> drm/rockchip: analogix: add eDP PSR function >> >> drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 69 ++++++++++++++ >> drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 5 + >> drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 54 +++++++++++ >> drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h | 28 ++++++ >> drivers/gpu/drm/rockchip/Makefile | 2 +- >> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 65 +++++++++++++ >> drivers/gpu/drm/rockchip/rockchip_drm_notify.c | 105 +++++++++++++++++++++ >> drivers/gpu/drm/rockchip/rockchip_drm_notify.h | 33 +++++++ >> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 96 +++++++++++++++++++ >> drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 3 + >> drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 2 + >> include/drm/bridge/analogix_dp.h | 3 + >> 12 files changed, 464 insertions(+), 1 deletion(-) >> create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_notify.c >> create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_notify.h >> >> -- >> 1.9.1 >> >> _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2016-06-01 2:54 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-05-31 13:37 [RFC PATCH v1 0/2] Yakir Yang 2016-05-31 13:37 ` Yakir Yang 2016-05-31 13:39 ` [RFC PATCH v1 1/2] drm/rockchip: add a notify event about vblank enable/disable Yakir Yang 2016-05-31 13:39 ` Yakir Yang 2016-05-31 14:36 ` Daniel Vetter 2016-06-01 2:52 ` Yakir Yang 2016-05-31 13:39 ` [RFC PATCH v1 2/2] drm/rockchip: analogix: add eDP PSR function Yakir Yang 2016-05-31 14:38 ` [RFC PATCH v1 0/2] Daniel Vetter 2016-05-31 14:38 ` Daniel Vetter 2016-06-01 2:41 ` Yakir Yang 2016-06-01 2:54 ` Yakir Yang [this message] 2016-06-01 2:54 ` Yakir Yang 2016-06-02 14:19 ` Daniel Vetter 2016-06-02 14:19 ` Daniel Vetter 2016-06-03 5:45 ` Yakir Yang
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=574E4E51.1030308@rock-chips.com \ --to=ykk@rock-chips.com \ --cc=airlied@linux.ie \ --cc=dan.carpenter@oracle.com \ --cc=daniel.vetter@intel.com \ --cc=dianders@chromium.org \ --cc=dri-devel@lists.freedesktop.org \ --cc=emil.l.velikov@gmail.com \ --cc=heiko@sntech.de \ --cc=inki.dae@samsung.com \ --cc=jingoohan1@gmail.com \ --cc=k.kozlowski@samsung.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-rockchip@lists.infradead.org \ --cc=linux-samsung-soc@vger.kernel.org \ --cc=tfiga@chromium.org \ --cc=treding@nvidia.com \ --cc=yzq@rock-chips.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.