[04/22,media] v4l2-subdev.h: add prepare_stream op

Message ID 20161007160107.5074-5-p.zabel@pengutronix.de (mailing list archive)
State Superseded, archived
Headers

Commit Message

Philipp Zabel Oct. 7, 2016, 4 p.m. UTC
  In some cases, for example MIPI CSI-2 input on i.MX6, the sending and
receiving subdevice need to be prepared in lock-step before the actual
streaming can start. In the i.MX6 MIPI CSI-2 case, the sender needs to
put its MIPI CSI-2 transmitter lanes into stop state, and the receiver
needs to configure its D-PHY and detect the stop state on all active
lanes. Only then the sender can be enabled to stream data and the
receiver can lock its PLL to the clock lane.

This patch adds a prepare_stream(sd) callback that can be issued to all
v4l2_subdevs before calling s_stream(sd, 1).

Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
---
 include/media/v4l2-subdev.h | 1 +
 1 file changed, 1 insertion(+)
  

Comments

Sakari Ailus Oct. 7, 2016, 11:16 p.m. UTC | #1
Hi Philipp,

On Fri, Oct 07, 2016 at 06:00:49PM +0200, Philipp Zabel wrote:
> In some cases, for example MIPI CSI-2 input on i.MX6, the sending and
> receiving subdevice need to be prepared in lock-step before the actual
> streaming can start. In the i.MX6 MIPI CSI-2 case, the sender needs to
> put its MIPI CSI-2 transmitter lanes into stop state, and the receiver
> needs to configure its D-PHY and detect the stop state on all active
> lanes. Only then the sender can be enabled to stream data and the
> receiver can lock its PLL to the clock lane.

Is there a need to explicitly control this? Shouldn't this already be the
case when the transmitting device is powered on and is not streaming?
  
Philipp Zabel Oct. 14, 2016, 3:48 p.m. UTC | #2
Am Samstag, den 08.10.2016, 02:16 +0300 schrieb Sakari Ailus:
> Hi Philipp,
> 
> On Fri, Oct 07, 2016 at 06:00:49PM +0200, Philipp Zabel wrote:
> > In some cases, for example MIPI CSI-2 input on i.MX6, the sending and
> > receiving subdevice need to be prepared in lock-step before the actual
> > streaming can start. In the i.MX6 MIPI CSI-2 case, the sender needs to
> > put its MIPI CSI-2 transmitter lanes into stop state, and the receiver
> > needs to configure its D-PHY and detect the stop state on all active
> > lanes. Only then the sender can be enabled to stream data and the
> > receiver can lock its PLL to the clock lane.
> 
> Is there a need to explicitly control this? Shouldn't this already be the
> case when the transmitting device is powered on and is not streaming?

Even if the transmitter is expected to keep the lanes in this stop state
all the time while the subdevice is powered but not streaming, I still
have to wait for stop state detection before enabling the transmitter,
and only then enable the reciever.
I'll remove the prepare_streaming callback in the next version and
instead let the subdevices propagate s_stream upstream instead in the
next version.

regards
Philipp

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  
Sakari Ailus Oct. 16, 2016, 10:59 p.m. UTC | #3
On Fri, Oct 14, 2016 at 05:48:43PM +0200, Philipp Zabel wrote:
> Am Samstag, den 08.10.2016, 02:16 +0300 schrieb Sakari Ailus:
> > Hi Philipp,
> > 
> > On Fri, Oct 07, 2016 at 06:00:49PM +0200, Philipp Zabel wrote:
> > > In some cases, for example MIPI CSI-2 input on i.MX6, the sending and
> > > receiving subdevice need to be prepared in lock-step before the actual
> > > streaming can start. In the i.MX6 MIPI CSI-2 case, the sender needs to
> > > put its MIPI CSI-2 transmitter lanes into stop state, and the receiver
> > > needs to configure its D-PHY and detect the stop state on all active
> > > lanes. Only then the sender can be enabled to stream data and the
> > > receiver can lock its PLL to the clock lane.
> > 
> > Is there a need to explicitly control this? Shouldn't this already be the
> > case when the transmitting device is powered on and is not streaming?
> 
> Even if the transmitter is expected to keep the lanes in this stop state
> all the time while the subdevice is powered but not streaming, I still
> have to wait for stop state detection before enabling the transmitter,
> and only then enable the reciever.
> I'll remove the prepare_streaming callback in the next version and
> instead let the subdevices propagate s_stream upstream instead in the
> next version.

Ack.

As discussed, I'll provide a patch to document this behaviour on CSI-2. I
believe the current drivers implicitly implement it but you're the first one
to ask the question. :-)
  

Patch

diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index cf778c5..6502f43 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -395,6 +395,7 @@  struct v4l2_subdev_video_ops {
 	int (*g_tvnorms)(struct v4l2_subdev *sd, v4l2_std_id *std);
 	int (*g_tvnorms_output)(struct v4l2_subdev *sd, v4l2_std_id *std);
 	int (*g_input_status)(struct v4l2_subdev *sd, u32 *status);
+	int (*prepare_stream)(struct v4l2_subdev *sd);
 	int (*s_stream)(struct v4l2_subdev *sd, int enable);
 	int (*g_pixelaspect)(struct v4l2_subdev *sd, struct v4l2_fract *aspect);
 	int (*g_parm)(struct v4l2_subdev *sd, struct v4l2_streamparm *param);