From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: kieran.bingham@ideasonboard.com
Cc: linux-renesas-soc@vger.kernel.org, linux-media@vger.kernel.org,
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v1 1/3] media: vsp1: Prevent resuming DRM pipelines
Date: Tue, 19 Sep 2017 11:46:36 +0300 [thread overview]
Message-ID: <2503926.ERnN7xSWg0@avalon> (raw)
In-Reply-To: <50ab72f2-0d08-f0ff-e4f5-45cd32d74894@ideasonboard.com>
Hi Kieran,
On Monday, 18 September 2017 03:04:13 EEST Kieran Bingham wrote:
> On 15/09/17 17:58, Laurent Pinchart wrote:
> > On Friday, 15 September 2017 19:42:05 EEST Kieran Bingham wrote:
> >> DRM pipelines utilising the VSP must stop all frame processing as part
> >> of the suspend operation to ensure the hardware is idle. Upon resume,
> >> the pipeline must not be started until the DU performs an atomic flush
> >> to restore the hardware configuration and state.
> >>
> >> Therefore the vsp1_pipeline_resume() call is not needed for DRM
> >> pipelines, and we can disable it in this instance.
> >
> > Being familiar with the issue I certainly understand the commit message,
> > but I think it can be a bit confusing to a reader not familiar to the
> > VSP/DU. How about something similar to the following ?
> >
> > "When used as part of a display pipeline, the VSP is stopped and restarted
> > explicitly by the DU from its suspend and resume handlers. There is thus
> > no need to stop or restart pipelines in the VSP suspend and resume
> > handlers."
>
> That's fine with me.
>
> >> CC: linux-media@vger.kernel.org
> >>
> >> Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
> >> ---
> >>
> >> drivers/media/platform/vsp1/vsp1_drv.c | 8 +++++++-
> >> 1 file changed, 7 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/media/platform/vsp1/vsp1_drv.c
> >> b/drivers/media/platform/vsp1/vsp1_drv.c index 962e4c304076..7604c7994c74
> >> 100644
> >> --- a/drivers/media/platform/vsp1/vsp1_drv.c
> >> +++ b/drivers/media/platform/vsp1/vsp1_drv.c
> >> @@ -582,7 +582,13 @@ static int __maybe_unused vsp1_pm_resume(struct
> >> device
> >> *dev) struct vsp1_device *vsp1 = dev_get_drvdata(dev);
> >>
> >> pm_runtime_force_resume(vsp1->dev);
> >>
> >> - vsp1_pipelines_resume(vsp1);
> >> +
> >> + /*
> >> + * DRM pipelines are stopped before suspend, and will be resumed after
> >> + * the DRM subsystem has reconfigured its pipeline with an atomic flush
> >> + */
> >
> > I would also adapt this comment similarly to the commit message.
> >
> >> + if (!vsp1->drm)
> >> + vsp1_pipelines_resume(vsp1);
> >
> > Should we do the same in vsp1_pm_suspend() ? I know it shouldn't be
> > strictly needed at the moment as vsp1_pipelines_suspend() should be a
> > no-op when the pipelines are already stopped, but a symmetrical
> > implementation sounds better to me.
>
> I'm OK with that, it's not needed - but it doesn't hurt to be symmetrical.
>
> (Updated locally for a v1.1 repost or such)
I've taken patches 2/3 and 3/3 in my tree so feel free to report 1/3 only.
> > I also wonder whether the check shouldn't be moved inside the
> > vsp1_pipelines_suspend() and vsp1_pipelines_resume() functions as we will
> > likely need to handle suspend/resume of display pipelines when adding
> > writeback support, but we could do so later.
>
> I'll have to retest the writeback implementation - but I think that has got
> quite stale now anyway and will need some rework.
Agreed, I don't expect it to work out of the box. We can move the check later
when rebasing the writeback patches.
> >> return 0;
> >>
> >> }
--
Regards,
Laurent Pinchart
WARNING: multiple messages have this Message-ID (diff)
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: kieran.bingham@ideasonboard.com
Cc: linux-renesas-soc@vger.kernel.org,
dri-devel@lists.freedesktop.org, linux-media@vger.kernel.org
Subject: Re: [PATCH v1 1/3] media: vsp1: Prevent resuming DRM pipelines
Date: Tue, 19 Sep 2017 11:46:36 +0300 [thread overview]
Message-ID: <2503926.ERnN7xSWg0@avalon> (raw)
In-Reply-To: <50ab72f2-0d08-f0ff-e4f5-45cd32d74894@ideasonboard.com>
Hi Kieran,
On Monday, 18 September 2017 03:04:13 EEST Kieran Bingham wrote:
> On 15/09/17 17:58, Laurent Pinchart wrote:
> > On Friday, 15 September 2017 19:42:05 EEST Kieran Bingham wrote:
> >> DRM pipelines utilising the VSP must stop all frame processing as part
> >> of the suspend operation to ensure the hardware is idle. Upon resume,
> >> the pipeline must not be started until the DU performs an atomic flush
> >> to restore the hardware configuration and state.
> >>
> >> Therefore the vsp1_pipeline_resume() call is not needed for DRM
> >> pipelines, and we can disable it in this instance.
> >
> > Being familiar with the issue I certainly understand the commit message,
> > but I think it can be a bit confusing to a reader not familiar to the
> > VSP/DU. How about something similar to the following ?
> >
> > "When used as part of a display pipeline, the VSP is stopped and restarted
> > explicitly by the DU from its suspend and resume handlers. There is thus
> > no need to stop or restart pipelines in the VSP suspend and resume
> > handlers."
>
> That's fine with me.
>
> >> CC: linux-media@vger.kernel.org
> >>
> >> Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
> >> ---
> >>
> >> drivers/media/platform/vsp1/vsp1_drv.c | 8 +++++++-
> >> 1 file changed, 7 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/media/platform/vsp1/vsp1_drv.c
> >> b/drivers/media/platform/vsp1/vsp1_drv.c index 962e4c304076..7604c7994c74
> >> 100644
> >> --- a/drivers/media/platform/vsp1/vsp1_drv.c
> >> +++ b/drivers/media/platform/vsp1/vsp1_drv.c
> >> @@ -582,7 +582,13 @@ static int __maybe_unused vsp1_pm_resume(struct
> >> device
> >> *dev) struct vsp1_device *vsp1 = dev_get_drvdata(dev);
> >>
> >> pm_runtime_force_resume(vsp1->dev);
> >>
> >> - vsp1_pipelines_resume(vsp1);
> >> +
> >> + /*
> >> + * DRM pipelines are stopped before suspend, and will be resumed after
> >> + * the DRM subsystem has reconfigured its pipeline with an atomic flush
> >> + */
> >
> > I would also adapt this comment similarly to the commit message.
> >
> >> + if (!vsp1->drm)
> >> + vsp1_pipelines_resume(vsp1);
> >
> > Should we do the same in vsp1_pm_suspend() ? I know it shouldn't be
> > strictly needed at the moment as vsp1_pipelines_suspend() should be a
> > no-op when the pipelines are already stopped, but a symmetrical
> > implementation sounds better to me.
>
> I'm OK with that, it's not needed - but it doesn't hurt to be symmetrical.
>
> (Updated locally for a v1.1 repost or such)
I've taken patches 2/3 and 3/3 in my tree so feel free to report 1/3 only.
> > I also wonder whether the check shouldn't be moved inside the
> > vsp1_pipelines_suspend() and vsp1_pipelines_resume() functions as we will
> > likely need to handle suspend/resume of display pipelines when adding
> > writeback support, but we could do so later.
>
> I'll have to retest the writeback implementation - but I think that has got
> quite stale now anyway and will need some rework.
Agreed, I don't expect it to work out of the box. We can move the check later
when rebasing the writeback patches.
> >> return 0;
> >>
> >> }
--
Regards,
Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2017-09-19 8:46 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-15 16:42 [PATCH v1 0/3] drm/media: Implement DU Suspend and Resume on VSP pipelines Kieran Bingham
2017-09-15 16:42 ` [PATCH v1 1/3] media: vsp1: Prevent resuming DRM pipelines Kieran Bingham
2017-09-15 16:58 ` Laurent Pinchart
2017-09-18 0:04 ` Kieran Bingham
2017-09-19 8:46 ` Laurent Pinchart [this message]
2017-09-19 8:46 ` Laurent Pinchart
2017-09-15 16:42 ` [PATCH v1 2/3] drm: rcar-du: Add suspend resume helpers Kieran Bingham
2017-09-15 17:02 ` Laurent Pinchart
2017-09-15 17:02 ` Laurent Pinchart
2017-09-15 17:49 ` Kieran Bingham
2017-09-15 18:20 ` Laurent Pinchart
2017-09-15 18:20 ` Laurent Pinchart
2017-09-15 16:42 ` [PATCH v1 3/3] drm: rcar-du: Remove unused CRTC suspend/resume functions Kieran Bingham
2017-09-15 17:06 ` Laurent Pinchart
2017-09-20 9:16 ` [PATCH v2] media: vsp1: Prevent suspending and resuming DRM pipelines Kieran Bingham
2017-11-12 16:37 ` [PATCH v2.1] " Kieran Bingham
2017-11-11 16:14 ` [PATCH v2] " Kieran Bingham
2017-11-12 4:28 ` Laurent Pinchart
2017-11-12 16:38 ` Kieran Bingham
2017-11-13 2:16 ` Laurent Pinchart
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=2503926.ERnN7xSWg0@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=kieran.bingham@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
/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: link
Be 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.