Message ID | 20161007160107.5074-5-p.zabel@pengutronix.de (mailing list archive) |
---|---|
State | Superseded, archived |
Headers |
Received: from mail.tu-berlin.de ([130.149.7.33]) by www.linuxtv.org with esmtp (Exim 4.84_2) (envelope-from <linux-media-owner@vger.kernel.org>) id 1bsXaQ-0000t2-SW; Fri, 07 Oct 2016 16:01:26 +0000 X-tubIT-Incoming-IP: 209.132.180.67 Received: from vger.kernel.org ([209.132.180.67]) by mail.tu-berlin.de (exim-4.84_2/mailfrontend-5) with esmtp id 1bsXaO-0006q1-6Y; Fri, 07 Oct 2016 18:01:25 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932421AbcJGQBT (ORCPT <rfc822;mkrufky@linuxtv.org> + 1 other); Fri, 7 Oct 2016 12:01:19 -0400 Received: from metis.ext.4.pengutronix.de ([92.198.50.35]:53298 "EHLO metis.ext.4.pengutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935466AbcJGQBP (ORCPT <rfc822;linux-media@vger.kernel.org>); Fri, 7 Oct 2016 12:01:15 -0400 Received: from dude.hi.pengutronix.de ([2001:67c:670:100:1d::7] helo=dude.pengutronix.de.) by metis.ext.pengutronix.de with esmtp (Exim 4.80) (envelope-from <p.zabel@pengutronix.de>) id 1bsXaD-0002OS-De; Fri, 07 Oct 2016 18:01:13 +0200 From: Philipp Zabel <p.zabel@pengutronix.de> To: linux-media@vger.kernel.org Cc: Steve Longerbeam <steve_longerbeam@mentor.com>, Marek Vasut <marex@denx.de>, Hans Verkuil <hverkuil@xs4all.nl>, kernel@pengutronix.de, Philipp Zabel <p.zabel@pengutronix.de> Subject: [PATCH 04/22] [media] v4l2-subdev.h: add prepare_stream op Date: Fri, 7 Oct 2016 18:00:49 +0200 Message-Id: <20161007160107.5074-5-p.zabel@pengutronix.de> X-Mailer: git-send-email 2.9.3 In-Reply-To: <20161007160107.5074-1-p.zabel@pengutronix.de> References: <20161007160107.5074-1-p.zabel@pengutronix.de> X-SA-Exim-Connect-IP: 2001:67c:670:100:1d::7 X-SA-Exim-Mail-From: p.zabel@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-media@vger.kernel.org Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: <linux-media.vger.kernel.org> X-Mailing-List: linux-media@vger.kernel.org X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.10.7.155117 X-PMX-Spam: Gauge=IIIIIIII, Probability=8%, Report=' MULTIPLE_RCPTS 0.1, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1500_1599 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, IN_REP_TO 0, LEGITIMATE_NEGATE 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, MULTIPLE_REAL_RCPTS 0, NO_URI_HTTPS 0, REFERENCES 0, SINGLE_URI_IN_BODY 0, URI_ENDS_IN_HTML 0, __ANY_URI 0, __CC_NAME 0, __CC_NAME_DIFF_FROM_ACC 0, __CC_REAL_NAMES 0, __CP_URI_IN_BODY 0, __FROM_DOMAIN_IN_ANY_CC2 0, __FROM_DOMAIN_IN_RCPT 0, __HAS_CC_HDR 0, __HAS_FROM 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __HAS_X_MAILING_LIST 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_TEXT_P 0, __MIME_TEXT_P1 0, __MULTIPLE_RCPTS_CC_X2 0, __REFERENCES 0, __SANE_MSGID 0, __SINGLE_URI_TEXT 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_IN_BODY 0, __URI_NO_WWW 0, __URI_NS , __URI_WITH_PATH 0' |
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
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?
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
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. :-)
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);