[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170620093729.4wldbtug4vdflcll@phenom.ffwll.local>
Date: Tue, 20 Jun 2017 11:37:29 +0200
From: Daniel Vetter <daniel@...ll.ch>
To: Noralf Trønnes <noralf@...nnes.org>
Cc: Liviu Dudau <Liviu.Dudau@....com>,
Mali DP Maintainers <malidp@...s.arm.com>,
LKML <linux-kernel@...r.kernel.org>,
DRI devel <dri-devel@...ts.freedesktop.org>
Subject: Re: [PATCH] drm: hdlcd: Update PM code to save/restore console.
On Mon, Jun 19, 2017 at 05:45:21PM +0200, Noralf Trønnes wrote:
>
> Den 19.06.2017 15.17, skrev Liviu Dudau:
> > On Fri, Jun 16, 2017 at 06:58:36PM +0200, Noralf Trønnes wrote:
> > > Den 16.06.2017 15.53, skrev Liviu Dudau:
> > > > Update the PM code to suspend/resume the fbdev_cma console.
> > > >
> > > > Signed-off-by: Liviu Dudau <Liviu.Dudau@....com>
> > > > ---
> > > > drivers/gpu/drm/arm/hdlcd_drv.c | 11 ++++++++++-
> > > > 1 file changed, 10 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
> > > > index d3da87fbd85a..89cd408cde6f 100644
> > > > --- a/drivers/gpu/drm/arm/hdlcd_drv.c
> > > > +++ b/drivers/gpu/drm/arm/hdlcd_drv.c
> > > > @@ -13,6 +13,7 @@
> > > > #include <linux/spinlock.h>
> > > > #include <linux/clk.h>
> > > > #include <linux/component.h>
> > > > +#include <linux/console.h>
> > > > #include <linux/list.h>
> > > > #include <linux/of_graph.h>
> > > > #include <linux/of_reserved_mem.h>
> > > > @@ -435,9 +436,15 @@ static int __maybe_unused hdlcd_pm_suspend(struct device *dev)
> > > > return 0;
> > > > drm_kms_helper_poll_disable(drm);
> > > > + console_lock();
> > > > + drm_fbdev_cma_set_suspend(hdlcd->fbdev, 1);
> > > > + console_unlock();
> > > You can use drm_fbdev_cma_set_suspend_unlocked() instead, it takes the
> > > lock for you and can speed up resume if the lock is contented.
> > Hi Noralf,
> >
> > Thanks for pointing out the helpful function. As you look to be the author of it,
> > any reason why the signature of the function doesn't match the drm_fb_helper_ one
> > being called through? (I'm talking about int vs bool for the state/suspend arguments).
>
> I don't remember, but probably to match drm_fbdev_cma_set_suspend()
> which uses int. drm_fb_helper_set_suspend*() uses bool, but calls
> into fb_set_suspend() which uses int, but as a boolean.
I'd be happy to apply a patch which changes them all to bool ...
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Powered by blists - more mailing lists