All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Longerbeam <slongerbeam@gmail.com>
To: Philipp Zabel <p.zabel@pengutronix.de>, linux-media@vger.kernel.org
Cc: stable@vger.kernel.org,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"open list:STAGING SUBSYSTEM" <devel@driverdev.osuosl.org>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/4] media: imx: csi: Allow unknown nearest upstream entities
Date: Mon, 21 Jan 2019 16:21:19 -0800	[thread overview]
Message-ID: <5e2d614a-ee1e-1ebc-f874-6bf4db22d52c@gmail.com> (raw)
In-Reply-To: <1548089410.3287.16.camel@pengutronix.de>



On 1/21/19 8:50 AM, Philipp Zabel wrote:
> On Sat, 2019-01-19 at 13:45 -0800, Steve Longerbeam wrote:
>> On i.MX6, the nearest upstream entity to the CSI can only be the
>> CSI video muxes or the Synopsys DW MIPI CSI-2 receiver.
>>
>> However the i.MX53 has no CSI video muxes or a MIPI CSI-2 receiver.
>> So allow for the nearest upstream entity to the CSI to be something
>> other than those.
>>
>> Fixes: bf3cfaa712e5c ("media: staging/imx: get CSI bus type from nearest
>> upstream entity")
>>
>> Signed-off-by: Steve Longerbeam <slongerbeam@gmail.com>
>> Cc: stable@vger.kernel.org
>> ---
>>   drivers/staging/media/imx/imx-media-csi.c | 18 ++++++++++++++----
>>   1 file changed, 14 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/staging/media/imx/imx-media-csi.c b/drivers/staging/media/imx/imx-media-csi.c
>> index 555aa45e02e3..b9af7d3d4974 100644
>> --- a/drivers/staging/media/imx/imx-media-csi.c
>> +++ b/drivers/staging/media/imx/imx-media-csi.c
>> @@ -154,9 +154,10 @@ static inline bool requires_passthrough(struct v4l2_fwnode_endpoint *ep,
>>   /*
>>    * Parses the fwnode endpoint from the source pad of the entity
>>    * connected to this CSI. This will either be the entity directly
>> - * upstream from the CSI-2 receiver, or directly upstream from the
>> - * video mux. The endpoint is needed to determine the bus type and
>> - * bus config coming into the CSI.
>> + * upstream from the CSI-2 receiver, directly upstream from the
>> + * video mux, or directly upstream from the CSI itself. The endpoint
>> + * is needed to determine the bus type and bus config coming into
>> + * the CSI.
>>    */
>>   static int csi_get_upstream_endpoint(struct csi_priv *priv,
>>   				     struct v4l2_fwnode_endpoint *ep)
>> @@ -172,7 +173,8 @@ static int csi_get_upstream_endpoint(struct csi_priv *priv,
>>   	if (!priv->src_sd)
>>   		return -EPIPE;
>>   
>> -	src = &priv->src_sd->entity;
>> +	sd = priv->src_sd;
>> +	src = &sd->entity;
>>   
>>   	if (src->function == MEDIA_ENT_F_VID_MUX) {
>>   		/*
>> @@ -186,6 +188,14 @@ static int csi_get_upstream_endpoint(struct csi_priv *priv,
>>   			src = &sd->entity;
>>   	}
>>   
>> +	/*
>> +	 * If the source is neither the video mux nor the CSI-2 receiver,
>> +	 * get the source pad directly upstream from CSI itself.
>> +	 */
>> +	if (src->function != MEDIA_ENT_F_VID_MUX &&
> Will it work correctly if there's an external MUX connected to the CSI?

By external MUX are you referring to some MUX that's external to the SoC 
(e.g. not the CSI muxes which are external to the IPU but internal to 
the SoC)? If so then yes it will still work (and of course it works if 
the MUX in question is the CSI muxes).

The function csi_get_upstream_endpoint() is only looking for, and stops 
at, the first sub-device that is external to the SoC, in order to 
determine the bus type coming into the SoC of the currently enabled 
pipeline. And that sub-device could be anything, including another MUX.

Steve

>
>> +	    sd->grp_id != IMX_MEDIA_GRP_ID_CSI2)
>> +		src = &priv->sd.entity;
>> +
>>   	/* get source pad of entity directly upstream from src */
>>   	pad = imx_media_find_upstream_pad(priv->md, src, 0);
>>   	if (IS_ERR(pad))
> regards
> Philipp


  reply	other threads:[~2019-01-22  0:21 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-19 21:45 [PATCH 0/4] media: imx: Various fixes for i.MX5 support Steve Longerbeam
2019-01-19 21:45 ` [PATCH 1/4] media: imx: csi: Allow unknown nearest upstream entities Steve Longerbeam
2019-01-21 16:50   ` Philipp Zabel
2019-01-22  0:21     ` Steve Longerbeam [this message]
2019-01-19 21:45 ` [PATCH 2/4] media: imx: Clear fwnode link struct for each endpoint iteration Steve Longerbeam
2019-01-19 21:45 ` [PATCH 3/4] media: imx: Rename functions that add IPU-internal subdevs/links Steve Longerbeam
2019-01-21 16:52   ` Philipp Zabel
2019-01-19 21:46 ` [PATCH 4/4] media: imx: Don't register IPU subdevs/links if CSI port missing Steve Longerbeam
2019-01-21 16:59   ` Philipp Zabel

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=5e2d614a-ee1e-1ebc-f874-6bf4db22d52c@gmail.com \
    --to=slongerbeam@gmail.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=p.zabel@pengutronix.de \
    --cc=stable@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.